| Handlebars.getTemplate = function(name) { | |
| if (Handlebars.templates === undefined || Handlebars.templates[name] === undefined) { | |
| $.ajax({ | |
| url : 'templatesfolder/' + name + '.handlebars', | |
| success : function(data) { | |
| if (Handlebars.templates === undefined) { | |
| Handlebars.templates = {}; | |
| } | |
| Handlebars.templates[name] = Handlebars.compile(data); | |
| }, |
| <?php | |
| /** | |
| * This file sets up exception and error handlers to log errors to our Graylog2 | |
| * server. | |
| * | |
| * @author Jeremy Cook | |
| */ | |
| //Add the autoloader generated by composer for dependencies. | |
| require_once 'path/to/composer/autoload.php'; |
rsync (Everyone seems to like -z, but it is much slower for me)
I'm having trouble understanding the benefit of require.js. Can you help me out? I imagine other developers have a similar interest.
From Require.js - Why AMD:
The AMD format comes from wanting a module format that was better than today's "write a bunch of script tags with implicit dependencies that you have to manually order"
I don't quite understand why this methodology is so bad. The difficult part is that you have to manually order dependencies. But the benefit is that you don't have an additional layer of abstraction.
| /* The Grid ---------------------- */ | |
| .lt-ie9 .row { width: 940px; max-width: 100%; min-width: 768px; margin: 0 auto; } | |
| .lt-ie9 .row .row { width: auto; max-width: none; min-width: 0; margin: 0 -15px; } | |
| .lt-ie9 .row.large-collapse .column, | |
| .lt-ie9 .row.large-collapse .columns { padding: 0; } | |
| .lt-ie9 .row .row { width: auto; max-width: none; min-width: 0; margin: 0 -15px; } | |
| .lt-ie9 .row .row.large-collapse { margin: 0; } | |
| .lt-ie9 .column, .lt-ie9 .columns { float: left; min-height: 1px; padding: 0 15px; position: relative; } | |
| .lt-ie9 .column.large-centered, .columns.large-centered { float: none; margin: 0 auto; } |
Ideas are cheap. Make a prototype, sketch a CLI session, draw a wireframe. Discuss around concrete examples, not hand-waving abstractions. Don't say you did something, provide a URL that proves it.
Nothing is real until it's being used by a real user. This doesn't mean you make a prototype in the morning and blog about it in the evening. It means you find one person you believe your product will help and try to get them to use it.
Attention: the list was moved to
https://github.com/dypsilon/frontend-dev-bookmarks
This page is not maintained anymore, please update your bookmarks.
Between us: [ProteusNet d.o.o., Rudarska cesta 11, 8281 Senovo, Slovenia, EU] and you: [partner]
We’ll always do our best to fulfil the scope of this cooperation, but it’s important to have things written down so that we both know what’s what, who should do what and when, and what will happen if something goes wrong. In this contract you won’t find any complicated legal terms or long passages of unreadable text. We’ve no desire to trick you into signing something that you might later regret. What we do want is what’s best for both parties, now and in the future.
So in short;
| <?php | |
| $config_options = array ( | |
| 'callback_excludes' => array( | |
| 'modSession', | |
| 'modManagerLog', | |
| 'modActiveUser', | |
| 'modDbRegisterQueue', | |
| 'modDbRegisterTopic', | |
| 'modDbRegisterMessage', | |
| 'modUser', |
For this configuration you can use web server you like, i decided, because i work mostly with it to use nginx.
Generally, properly configured nginx can handle up to 400K to 500K requests per second (clustered), most what i saw is 50K to 80K (non-clustered) requests per second and 30% CPU load, course, this was 2 x Intel Xeon with HyperThreading enabled, but it can work without problem on slower machines.
You must understand that this config is used in testing environment and not in production so you will need to find a way to implement most of those features best possible for your servers.