The protractor.conf.js file is meant to offer a configuration for our e2e tests. The default which come with each new angular-cli app is very good and works really well. We shouldn't extend it unless we expect more.
Although it works well on localhost, what about the CI server?
On this post I wont explain what kind of configuration you might need for your CI, but how to separate the configuration and how to use it
As web developers we have been developing web forms almost on every app. How many times have you spent time searching on google (or bing - no offense ) on finding solutions to pre-select an option on a select control while using angular? Yeah I know! Many times. And when you read the solution you are like "Ohh yess!"
Let's demystify this
What are the differences? The main difference is the scoping
In nutshell, block scope is the code that is enclosed in curly braces
Node.js is single threaded and by default utilizes only one core of the CPU no matter how many cores the CPU has. Of course there are solutions of how to use all the cores but it's not part of this post. Just for the record, there are packages that does this job efficiently. Have a look at this link pm2.keymetrics.io/
Well, what am I trying to solve here? Imagine that you have 2 different endpoints on your application, and one of them needs a lot of processing time. What the problem would be?
What are the promises?
A promise is an alternative way which allows us to handle asynchronous operations in a more elegant way than callbacks
Let's assume a simple story which will help us understand this. (well OK, I know that its not the best example you've ever read)
A father asks his son to go and buy a newspaper. The father is awaiting for the newspaper and will start reading it when his son returns back. On the other hand, the father knows that his son, who loves playing out in the yard, has some possibilities to fall down and start crying. In this case he won't read his newspaper and he will have to care of his son.
There are two cases in the story; the father will read the newspaper. The father won't read the newspaper.
* In the company that I work for, we have a ceremony, called DOJO, in which any employer can present his/her ideas about any subject he/she wants to share (though we are trying to be focused on technological stuff). As such, this slide presentation was one of our DOJOs
Recently I met the "pair programming" term, which refers to two developers working together in the same task.
There are plenty ways for this to happen. The most common though is that a developer writes code, whereas the other shares ideas.
Are you a back-end developer?
I have discussed with many developers that tend to be a sort of full stack developers and if you ask them about their position they reply that they are back-end developers. It seems that it exists an inexplicable reason of making the developers believe that back-end is 'harder' than the 'front-end' and of course the harder way, the better developer. (I am not fond of this idea).
Do what ever you want but be GOOD at it!
The wrong way
I found it interesting to start writing this article by explaining the wrong way of designing an angular application.
The so common way to design an application is to group your modules (controllers, routes, services, factories, directives etc). The controllers to be in a controllers.js file, the services to be in a services.js file and so on. None can say that this is a bad design, but you will notice in the near future that this is not a so maintainable design because it's hard to find and amend a route that is inside the routes.js file and this file has more than 100 routes.
Before diving into details in the matter of full stack applications, I would like to point out the reasons that make me start searching of something like this. You might ask "something like what?" :).
Well, firstly I started experimented with angular generator for creating a single page application that would connected with a REST API. But what about if I wanted to make any heavily data manipulation or anything sensitive? In the other hand, I met NodeJs' sockets and I would probably wanted to use them in future.
For avoiding combine express with angular in a later stage, I decided to do it from beginning.