Let’s continue our journey into the universe of Angular2 with exploring forms. Actually, that’s something odd: many articles and tutorials on Angular2 spend a lot of time explaining that the old two-way-binding of AngularJS 1.x has been replaced by something different, something superior.
Putting it in a nutshell
Forget about that. You can learn about the subtleties of Angular2 later. From a beginners view of point, good old two-way-binding is still there. It even has become more simple.
Putting it in a nutshell, you simply use the new, slightly controversial syntax
<input [(ng-model)]="someProperty" /> to bind an input field directly to a property called
someProperty of your controller. Initially, the input field is populated with the value
someProperty, and when the user starts to type in the input field, every key stroke immediately changes the variable
In one or two of my recent posts, I claimed that the TypeScript compiler is extremely fast, and that that Google Chrome caches your TypeScript code to aggressively.
Both things have changed since then. The bad news is that the editor I use, Atom, has started to compile the entire project each and every time I edit a file. I don’t know whether this is a configuration error of mine, or if it’s a bug of Atom, or even a peculiarity of the current version of TypeScript. I’m positive the error is on my side, but as long as I haven’t found the reason I reluctantly have to revoke my claim that TypeScript compiles in virtually no time.
Now for the good news. The Angular2 team recommends to use “live-server”, and it works just great. Install it via
npm i typescript live-server --save-dev
Next, open the file
package.json, find the
scripts section and replace it with
"tsc": "tsc -p src -w",
"start": "live-server --open=src"
Now you can start your project by starting
npm start at the command line. This starts the server, opens the browser, opens the index.html of your project within the browser and – that’s the really cool part – restarts your application each time you edit a file.
Read the full story at the Angular2 quickstart tutorial.
Do you remember how disturbing the initial announcement of Angular2 was? As far as I remember, it was at ngEurope, roughly 12 months ago. At the time, the Angular team said there wasn’t a migration plan. I guess they should have added the word “yet”. Most developers and project managers understood there wouldn’t be a migration plan at all. Many of them saw the future of their AngularJS projects in tatters.
Well, that was premature. It’s far from being impossible to migrate from AngularJS 1.x to Angular2. Quite the contrary, there’s even a project dedicated to make the migration as smooth and easy as possible. Or, as Pascal Precht and Misko Hevery put it, boring.
Today I’ve stumbled upon an in-depth analysis of how to use the project, which is called – guess what – ngUpgrade. Read the full story written by Pascal Precht. It’s a great read, and I’m sure it’ll be useful to many Angular 1.x project teams. Highly recommended!
By the way, that’s not the only great news for those of us working for major companies: According to Brian Green’s announcement at the AngularConnect 2015 conference in London, Angular2 is going to support Internet Explorer 9 and 10 (at 53’40”).
Nobody knows when Angular2 is going to be released. Chances are this includes the Angular team (although they don’t tell us). So people start to try to look into the crystal ball. One thing is that the API feels mature. Granted, it still happens to break more often than is to my liking, but the basic design decisions seem to have been done. Another indicator for the progress is the documentation site. The developer guide is still incomplete, but it’s growing by the day.
Another indicator is the progress on the open tickets. Currently, each day 2.2% of the open tickets are solved. Judging by this measure, the release date of Angular2 isn’t far away. Actually, the Angular 2 Beta Burndown Chart indicated Angular2 is going to be released in 2015.
Personally, I think that’s nonsense – there’s more to releasing software than just closing tickets on the bug tracker – but it’s a good idea. Plus, it’s fun, and it looks great.
There’s only one thing that’s odd: the burndown chart isn’t an Angular application. Let alone an Angular2 application.
Update Nov 9, 2015:
My article and my tweet about it started a funny discussion, which lead to an full-blown Angular2 implementation of the Angular2 Release Date Projection tool. Sometimes it’s fun to be a catalyst :).
Update Nov 17, 2015:
In the meantime, the release projection has been migrated to Angular2. It’s really fun to be a catalyst!
Since I started my AngularJS 2.0 series, AngularJS has evolved considerably. Version numbers went up from 2.0.0-alpha.36 to 2.0.0-alpha.45. Plus, they’ve added quite a lot of content to the documentation pages. So I wasn’t surprised it took me two evenings to update my AngularJS 2.0 chess demo to the actual version. However, this turned out not to be Angular’s fault: the library responsible to deal with Angular’s module system,
System.js, introduced one or two breaking changes. The good news being: the API of Angular 2 is pretty stable, stable enough to continue with a couple of hands-on articles.
Today, I’d like to make you familiar with the basic concepts of Angular 2. Let’s write your first application together. Or rather – well, writing a simple demo application is something virtually every tutorial does. Let’s tackle Angular 2 from a different Angle. I’ve uploaded a slightly simplified version of my Angular 2 chess program on GitHub. So you can start with a real-world application. I won’t explain every feature of the chess program – that’d be an entire book, not a blog entry. This article simply gives you a head start to grasp the look and feel of an Angular 2 application, and to play with it.
Curious? Clone the repository at https://github.com/stephanrauh/ExploringAngular.git and open the subfolder /Blog01. That’s a full-blown, running Angular 2 application. Let’s examine it step by step.
I always wondered how to write truly efficient and useful unit tests. So I’m glad my co-worker Thomas Papendieck offered to write a guest article, sharing his expertise with you. Thomas, it’s your stage!
Unit tests are cool!
Unit tests secure already existing behavior in the code base and support the programmer while doing changes by detecting damages.
Almost every programmer knows this statement.
…but are they really?
On the other hand almost every programmer made the opposite experience: Unit tests come in the way of the programmer when she wants to introduce changes to the production code. After the change a whole bunch of unit tests broke and it takes a big effort to make them pass or even compile again. I remember projects where fixing tests took up to ten times longer that the actual change.
Why does that happen? Is it that unit tests are only hyped by ivory-tower screwballs propagating academic ideals? Those lucky dreamers never being responsible for a real life application?
The staggering answer is: No.
Granted, I can hardly call the news of this newsflash “new”: it has been published Sept 01, 2015. But it’s very interesting nonetheless. The AngularJS team’s blog has the results of a survey asking developers what they expect of Angular 2. Each survey result is spiced with an in-depth analysis, many of which provide additional information about Angular 2. Highly recommended.
Read the survey results at http://angularjs.blogspot.de/2015/09/angular-2-survey-results.html.
There are all these wonderful tools for profiling Java programs. JVisualVM, JProfiler, Mission Control and the Flight recorder, jhat, just to name a few. Yet every once in a while, you can’t use any of them, for one reason or another. Where do we go from here?
How come there’s no profiler?
The situation is not quite as exotic as you may think. When I was asked recently to write programs in the middleware layer, the lack of tools was the one of the reasons why I denied. More precisely, I was asked to write Java programs running in the webMethods ESB. In theory, that’s a great idea, but the lack of tools makes programming a pain. No debugger. No profiler.
In theory, you can debug such a program using remote debugging, but that requires many preconditions to be fulfilled. The administrator has to start the program with additional parameters, and they have to open the ports in the firewall. Sometimes that’s possible in the development and test stages, but usually it’s completely out of question in the production stage.
However, being a consultant, sometimes I’m asked to help our customer nonetheless. Continue reading
My previous article focused on what the MV* paradigms are. But it didn’t answer the question whether using one of the MV* patterns is worth the pain. One thing is for sure: none of the MV* paradigms comes for free. It depends on your project whether using an MV* patterns is a wise investment or a waste of time and money.
Dissecting a chess application
For instance, consider my AngularJS 2.0 chess program (see the source code at GitHib or play it at AngularFaces.com/chess). It doesn’t follow any particular architectural pattern. Or rather, it doesn’t follow one of the established MVW patterns. To begin with, there’s no model. I simply didn’t need it. The program’s data are stored in the controller component of the program. I don’t know all the subtleties of the MV* theory, but I guess it’s OK to say the chess demo stores its data in the viewmodel layer.
Actually, the chess demo doesn’t consist of many layers. There’s the HTML code, there’s the chess engine and there’s some glue code.
My previous post (and the majority of tutorials) claims that AngularJS favors the MVVM pattern. Let’s stick to this fiction for a moment. It’s easy to identify the view layer: that’s the HMTL pages and the CSS stylesheets. The glue code is the viewmodel. I already said that there’s no need for a model layer.
Bruce Eckel has published some interesting thoughts about closures and lambda expressions in Java 8. He claims that Java’s lambdas are essentially closures because the original definition of closures stems from functional programming languages, and pure functional languages don’t know variables. Hence, Java’s restriction that lambdas can only access effectively final variables of the surrounding scope is not a real restriction, he claims. Plus, it can be circumvented by encapsulating the interesting variable in an object. Basically, that’s the same trick Java programmers use to implement call-by-reference parameters.
I can’t say I really agree with Bruce Eckel. In my eyes closures are a lot more useful than lambda expressions because they can access variables of the surrounding scope, while lambda can only access constant values of the outer scope. But it’s an interesting article nonetheless. Read the full story on Bruce Eckel’s blog.
These days it’s kind of official: AngularJS implements the Model-View-Whatever paradigm. That’s a nice solution to a series of fruitless discussions about whether AngularJS implements MVVM, MVC or something else.
However, one of these days I stumbled upon a couple of slides claiming AngularJS implements the MVC pattern during my research for another article. I knew from various tutorials that this isn’t exactly true. My curiosity was piqued. What exactly is the difference between MVC, MVVM and MVP? Are there other useful design patterns? And while we’re at it: do JSF and AngularJS implement one of these design patterns?
Actually, I already knew there are different design patterns you can use successfully. When I implemented my former company’s framework, I got the idea of MVC wrong. So I implemented something slightly different. That earned me a lot of trouble with external consultants. You know, every once in a while we invited a consultant to look over our architecture. Inevitably, they would complain about our non-standard implementation. But our implementation worked, and it worked well, so what?
That’s an important thing to keep in mind: don’t waste your time on this nonsense. It’s like talking about politics: it’s a lot of fun to discuss about the advantages of MVP over MVC and whether your program following on paradigm or the other. But at the end of the days, it’ll change little. It’s more important to chose a clean, sustainable architecture and stick to it. If you need a name, call it Model-View-Whatever. Whatever works for you.
But today I’m not going to listen to the voice of reason. Today I want to have fun. Let’s dissect the design patterns, and let’s see how JSF and Angular fit into the pattern.
At a glance
Look at these pictures. They cover three of the most popular patterns: MVP, MVC and MVVM. Don’t soak yourself in the details – that’s what the rest of the article is about. Just look at the general picture. Do you notice anything?
So, I’ve decided to write a tiny tutorial on TypeScript. It’s not an exhaustive step-by-step tutorial. I can’t beat the official TypeScript manual, so I won’t even try. Instead, I’ll give you a short tour-de-force from a Java programmers perspective.
Live in the early days of AngularJS 2.0
Probably it’s still a bit early to investigate AngularJS 2 thoroughly. The release date of AngularJS 2 is still open, documentation is scarce and I’m told many important APIs are still unfinished. But that’s the fate of an early adopter. On the other hand, it’s already possible to work with the current Alpha versions, and if I’m not mistaken the fundamental decisions of what AngularJS 2 is going to look like already have been made. So I thought by myself that the time is ripe to explore AngularJS 2. Along the way, I wrote a little chess program consisting of 1500 lines, give or take a few.
Cutting a long story short: AngularJS 2.0 is fun, even today. It’s a big step forward.
Some time ago, I wrote about the challenges of getting JSF in a Spring Boot container up and running. The problem is that Spring Boot is officially not supported by the Mojarra team, which means it’s up to the Spring Boot team to ensure compatibility.
The Spring Boot ticket Phil Webb opened in response to my article is still open, but he pointed me to an interesting article. Alex Bath of Oakdale Software managed to run a JSF application on Apache MyFaces 2.2.6.
However, I suspect that compatibility between JSF and Spring will deteriorate more and more in the (possibly near) future. If I’m not mistaken, JSF is going to be tightly integrated with CDI, so many interesting features simply won’t work without CDI. On the long run, this may render JSF useless without CDI.
That said, I’d like you to point to the GitHub repository of the project of Alex and invite you to read the full story.
Ten years ago, this question would have been heresy. Even today, it’s perfect to start a lively discussion, as Eberhard Wolff did today on Twitter. Object oriented programming still has a lot of defenders (including me), but recently the critics are gathering, too (also including me). So what is it that makes people skeptical about object oriented programming?
On August 19, the Bootstrap Team has released the first alpha version of the fourth major release of their widely adopted front-end framework. Roughly two weeks later, August 31, they published their second alpha version.
State of the art
Please take this article with a grain of salt: the release post lists many highlights, many changes this version is going to bring out, but currently we are still talking of the first alpha version, so some things might change until we reach the final release.
One of the implementation details of JSF hardly any developer knows anything about is the hidden field “javax.faces.ViewState” that’s included in every JSF view. On the one hand, it’s good that you don’t have to know anything about this field. Thing is, this lack of knowledge is filled with many myths. One of these myths is that the view state protects JSF pages against “cross-site request forgery attacks” (CSRF for short). Which is true, but it’s not the primary purpose of the field.
I started to investigate the topic because our professional penetration tester managed to run a CSRF attack using a simple replay script. He made me believe that the view state doesn’t protect JSF application against CSRF attacks. But what is it for? And while we’re at it, how to protect your application against CSRF?
A lot has been complained about the hard cut between AngularJS 1.x and AngularJS 2.0. In the early days of AngularJS 2, the Angular team announced to have started a complete rewrite of AngularJS, without trying to remain compatible. The reaction of the community was harsh: many developers turned away from Angular.
Maybe this has been to early. Today, the Angular team announced to plan a surprisingly tight integration between the two versions. According to their blog, you can
So, starting a series of Angular 2 articles inevitably includes a number of articles about TypeScript. BeyondJava.net already published such an article some time ago, but that was before the release of TypeScript 1.5, so it’s time to deliver an update. During my research I stumbled upon an interesting article: The rise of TypeScript?”. I wasn’t even aware that TypeScript is on the rise, but since I’ve read the article I guess the author can safely omit the question mark. He gives a number of good reasons why TypeScript has an opportunity to lift off.