FWIW: I didn't produce the content present here. I've just copy-pasted it from somewhere over the Internet, but I cannot remember exactly the original source. I was also not able to find the author's name, so I cannot give him/her the proper credit.
| ## On Windows: | |
| ``http://www.graphicsmagick.org/INSTALL-windows.html`` | |
| ## On the Mac: | |
| ``brew install graphicsmagick`` | |
| ## On the Joyent box: | |
| ``` |
git branch --merged master | grep -v "\* staging" | xargs -n 1 git branch -d
Written by Joe Eames, Creator of 18 Pluralsight courses & ng-conf
One of the very common surprises that people have when learning about Angular 2 is its close ties with TypeScript. This relationship seemingly came out of nowhere, and many people have been asking questions about this. Additionally, developers may feel a little trepidation when faced with learning yet again something new. So let’s get a quick look at not only the rationale, but the absolute basics and how much of an additional learning curve TypeScript might add when learning Angular 2.
History It’s easier to understand the present by understanding the past. When the Angular team started on Angular 2, they realized that with such a large undertaking, that having types would eliminate a large segment of possible bugs as they wrote the code for the framework. So internally they were interested in adding types to JavaScript. Furthermore, the dependency injection system of Angular 2 works better with types. So there was a good reason to use type
Written by Joe Eames, Founder, ng-conf (the AngularJS conference)
Angular 2 is just about to release, and many developers are asking themselves, “should I learn Angular 2?” The short answer is yes, but we’ll look at some of the reasons why.
First, it’s a good idea to understand where front end web development is at currently. A few short years ago, there were very few choices, but today, we have quite a few very good frameworks to choose from. This is a better situation than when there were no choices, but it can also lead to analysis paralysis, where we can’t make a decision because there’s just too many good choices. In addition, we have seen a recent rash of tool fatigue - developers complaining that there is just too many moving pieces in even a simple app, and for new developers especially, this can be a particularly challenging environment in which to try to get work done.
Angular 1
Although Angular 1 is a great framework, it’s beginning to show its age. Even though it is still gaining popularity,
| Main Reason | |
| HA - High Availability | |
| Data Safety | |
| General Info | |
| Replication is Async | |
| And Can have ACK | |
| Single Primary (No direct Eventual Consistency) | |
| Has somewhat Statement Based Replication (Not Binary Based) | |
| It creates one statement for document even if your query is single line (But it may affect multiple documents) |
| In root directory type this command: | |
| 1 | |
| 2 | |
| 3 | |
| <b> | |
| mkdir src | |
| </b> | |
| Type this command | |
| 1 | |
| 2 |
They say that one of the pros of NodeJS is that you use the same language on the back-end and the front-end, so it's easy to share code between them. This sounds great in theory, but in practice the synchronous dependency handling in NodeJS works completely different than any client-side frameworks (which are asynchronous).
Usually that means that you end up copy-pasting your code between your NodeJS sources and your client-side sources, or you use some tool like Browserify, which is brilliant, but they add an extra step in the build process and most likely will conflict with the dependency handling of the framework of your choice (like AnularJS DI). I couldn't look in the mirror if I would call that code sharing.
Fortunately, with a couple of lines of boilerplate code, you can write a module which works in NodeJS and AngularJS as well without any modification.
No globals in the front-end, and dependencies will work. The isNode and isAngular va
Reference and recommand read from http://speakingjs.com/
JavaScript has only six types
Undefined, Null
Boolean, String, Number, and
Object
JavaScript makes a somewhat arbitrary distinction between values:
The primitive values are booleans, numbers, strings, null, and undefined.
All other values are objects.
Unit test: If you are testing one small module of your application, you are writing a unit test. You’ll need to stub and mock other modules that your module usually leverages in order to isolate each test. You’ll typically also need to spy on actions that the module takes to verify that they occur.
Integration test: If you are testing that multiple modules behave properly in concert, you are writing an integration test. Such tests are much more complex and may require running code both on the client and on the server to verify that communication across that divide is working as expected. Typically an integration test will still isolate a part of the entire application and directly verify results in code.
Acceptance test: If you want to write a test that can be run against any running version of your app and verifies at the browser level that the right things happen when you push the right buttons, then you are writing an acceptance test (sometimes called “end to end test”). Such test