honglio / niukj Goto Github PK

slow connection hate http requests, so we need to reduce the request time as little as possible.

Convert WOFF 1.0 to 2.0

We can use https://github.com/gruntjs/grunt-contrib-compress

But we need to figure out what can be gzip and what can't.

The behavior should be drap&drop, not jump out on slide edit board.

merge some feature from design-template project

Convert "make build" to use grunt.

Requires:

Compiling LESS files
Compiling Jade files in lib/client
Building all components
Concatenation?
For a subsequent issue we'll use grunt watch to perform these steps.

Watch will (wait for it) watch various files, and perform specific tasks whenever one of those files changes

watch: {
      files: ['css/*', 'js/*'],
      tasks: ['concat', 'cssmin', 'uglify']
}

Waiting for whole site redesign.

• Small file sizes that compress well
• Scales to any size without losing clarity (except very tiny)
• Looks great on retina displays
• Design control like interactivity and filters

grunt-filerev seems to do the same as grunt-smartrev once you add in grunt-filerev-replace. smartrev by default will version and update both files as well as dependencies. e.g. if a jpg changes then not only will it get a new hash, but the link will be updated in any associated CSS and therefore that CSS gets an update too.

A further challenge is then how to reference these assets from dynamic pages (e.g. Express). For this, we have custom code to read the smartrev output. I see there is yet another complimentary filerev plugin here: https://github.com/richardbolt/grunt-filerev-assets. grunt-usemin seems similar but designed more for static HTML pages rather than dynamically generated ones.

https://developers.google.com/speed/docs/insights/BlockingJS

1. Do we just add 'async'? we should use: http://www.dustindiaz.com/scriptjs
   Use it to load multiple JS scripts on the same page asynchronously.
2. Replace the current link CSS.

I want to let etch to handle this, and I want to ensure that a Link (URL) opens in a new Window/Tab without disturbing the presentation. We need to added target="_blank" by default to links.

Aren't we using Bootstrap LESS to pick and choose which styles are needed?
Component bundling into a few different files, one of which is the minimum necessary CSS for landing pages
Using grunt-uncss to remove unused CSS (some risk of it causing problems, but may be worth it)

Most important to start with are:

Establish a baseline (i.e. one or more measurements for performance to compare future improvements against)
CSSLint to make sure we don't break things.

Caliper seems like a great fit for us so let's try it out.

I've been given a private signup.

We need this at the top of the

, only needed on /condo-search:

Now, download this file: https://d2yr92gots5pio.cloudfront.net/caliper.ember-0.0.3.min.js
It must be included after ember.
They have a help article for AMD/RequireJS but I don't think that applies to our component.json approach?

One thing I'm not sure of is whether we should make this an optional include, such as for running only in production later. If it's optional (i.e. controlled by environment variable), I'm not sure if we have the capability to build/not-build it via component? Anyway, for now we'll want to test it everywhere so no harm baking it in permanently for the short term.

Theme button is a drop-down button of 9 theme option. When user choose one theme, it add several textbox with pre-defined font color, size, margin, line-height in operating table, and the background-color also changed to pre-defined color. Theme button should right before background button. e.g.

This issue is to discuss/define a future approach to functional testing.

First of all, for unit testing I think it's easy - we test everything, every time, locally.

For functional testing, there are essentially three approaches we'll combine:

Local, headless testing using PhantomJS (the fastest way possible)
Local, real browser testing using Chrome and Firefox on localhost via Selenium Webdriver
Hosted, real browser testing (including mobile) using Saucelabs
Local headless testing is what we are doing today with CasperJS. The problem with this is that bugs specific to certain browsers can easily be introduced, and we've seen that already with IE, Firefox and Mobile Safari examples. CasperJS has no way to extend its testing to real browsers, so we'd have to write everything twice. So that's why CasperJS is to be deprecated in this project.

The better way to do local headless testing is using a functional test library that supports the Selenium webdriver, so that tests can be switched between PhantomJS or real browsers locally, or even hosted ones such as Saucelabs.

For Local, real browser testing, we would use Chrome and Firefox on SauceLab and integrate it into Codeship, so we have a CI to support functional testing.

For Hosted, saucelabs seems best for now (and cheaper).

The idea I have in mind currently is:

1. Run local headless functional testing for every commit
2. Run local firefox/Chrome testing for commits to master (i.e. prior to production)
3. Run saucelabs testing for special features or if we have doubts

There are a couple of work around for the 200/300 ms delay in touch
the problem is that those solutions are mostly vendor specific (every browser define it's own solution)
the most common and easier one is using touch events (touchstart, touchend) since those events does not have the delay in them.

https://github.com/leongersen/noUiSlider - implement this solution (along side with some CSS adjustment).

https://github.com/ftlabs/fastclick - Applying a website wide solution (like fastclick) may cause performance issues.

Seems Kendo UI performance is not perfect either: http://www.telerik.com/forums/performance-issues-51e3e41dc6ea
What's strange is that they seem aware of the situation but hesitant to adopt or copy something like Fastclick. Earlier they claimed the didn't have the general 300ms problem though: http://blogs.telerik.com/appbuilder/posts/13-11-21/what-exactly-is.....-the-300ms-click-delay

the best library https://github.com/filamentgroup/tappy

Currently, the intern home page testing does nothing more than verify that the page loads and checks the title.

This testing should be extended to check things like:

1. Clicking the Learn More button scrolls the page down
2. The top menu appears after this
3. Top menu buttons takes users to correct pages
4. Search Condos button takes user to /condo-search
5. Login menu causes modal popup and pressing Cancel successfully clears it

Additional tests can be added to this too, if desired.

use https://github.com/linkedin/hopscotch, it's already in home page. we just need to take it out and apply it to slide editor page.

This proposition removes per request builds and introduces:

Watching lib/client/* and building to public.
Watching public and reloading browser page.
Watching lib/server/*, reloading the server and reloading browser page.
We could use https://github.com/nodejitsu/forever-monitor, probably with grunt-watch. This is ready to start.

the deleted slides or components is remain.

http://theintern.io/

image url is already support http://. This will solve #16.

waiting for the local test process has setup. #6

Winston should send emails (via nodemailer) based on configurable thresholds (e.g. EMERGENCY, CRITICAL, etc).

Winston offer 3 logging levels norms by defaults npm syslog and cli, I chose npm

silly: 0
debug: 1
verbose: 2
info: 3
warn: 4
error: 5
https://github.com/flatiron/winston/tree/master/lib/winston/config

http://www.luster.io/blog/9-29-14-mobile-web-checklist.html

1. 去掉多余的边框，用纯色背景来区分不同区域。
2. 在点击课件页snapshot时，此snapshot背景应该变色，且右边与编辑区域连成一片。

参见http://huaban.com/pins/265792672/

This title is miss leading. The problem is that user can't upload file more than 380k using base64 in chrome.

Bust the user's cache only when they change.

grunt test-dev for unit testing

Added grunt-jscs for testing grunt-jsbeautifier for fixing & testing

@media screen and (max-width: 479px) {

• @media (max-width: @screen-xs-max)
  }

@media (min-width: 480px) and (max-width: 766px){

• @media (max-width: @screen-sm-max)
  }

@media (min-width: 767px) and (max-width: 1079px) {

• @media (max-width: @screen-md-max) {
  }

@media (min-width: 1080px) {

• @media (min-width: @screen-lg-min)
  }

Evaluate https://github.com/danielstjules/jsinspect

Evaluate https://github.com/danielstjules/buddy.js