Gone are the days of customizing Bootstrap with the sweat of your brow. At least if you’re using a current version of Angular and Bootstrap 4. Mind you: Bootstrap 4 is built with SASS. Angular supports SASS as a first-class citizen. So it’s hardly surprising that it’s a child’s game to customize Bootstrap with an Angular application.
Basically, you have to follow these four steps:
That’s it! Now you can customize Bootstrap by editing the
The Angular Animations API adds a shallow abstraction layer to the animations offered by CSS. It’s a bit like so many other Angular libraries: it adds enough syntactic sugar to make it useful, but it adds little value to the underlying technology.
At least, that was my first impression. During my research for this article, I’ve learned that such a shallow abstraction layer make a lot of sense. For instance, the same API could be used with AngularNative. As far as I know (correct me if I’m wrong!), that’s not the case today, but who knows what the future has in store for us.
’nuff said. Let’s get our feet wet with real source code. Have you ever seen at the back-side of your application? This demo doesn’t work with Internet Explorer because I wanted to keep the source code of the demo simple, so please use another browser to see the animation:
Today’s tech tip is almost too primitive to mention. However, on second glance, it shows how to use Angular efficiently. I reckon there’s a general pattern there, even if I haven’t been able to distill it yet to make it a textbook lesson.
Consider a carousel, such as the first demo at our BootsFaces showcase. It displays three images. At every point in time, only one of the three images is shown, unless you click to show the next image. In that case, the next image starts to slide into view, replacing the old image.
Things get ugly if we’ve got hundreds of images. They also get ugly if the carousel is used to implement a wizard. Chances are that the content of the second page of the wizard depends on the input provided on the first page of the wizard. In other words, the second page can’t be rendered at load time. As you can imagine, our use case was a combination of these two options.
The other day, I was asked to compare frameworks like Angular and React.js. It was an interview, so I didn’t notice the tiny slip. Developers reading the interview didn’t hesitate to point out that React is a library, not a framework. A few months earlier other developers reminded me you can’t compare Angular with React because the former is a framework, while the latter is not.
The reactions of the community where so emotional that I gather many people consider it an important difference. That, in turn, means it’s fun to play devil’s advocate. It’s the kind of games generating new insights.
Image source: PixabayThe age of a programming language shows in the clever tricks programmers use. One such trick is used by CDI. Did you ever wonder why you have to put an empty
beans.xml into the
By the way, you may not even aware that the
beans.xml is allowed to be empty. Many developers aren’t. You can use the
beans.xml to configure a couple of things, leading developers to believe they have to do that. Plus, the IDEs tend to complain about an empty XML file because they consider it ill-formed. As far as I know, Netbeans generates a non-empty
beans.xml by default. But still, even if you haven’t seen it yet, it’s allowed to put an empty
beans.xml into the
META-INF folder of your jar (or the
WEB-INF folder of your *.war file). Empty meaning really empty: it’s a file of zero bytes length.
What good is such a weird file?
We’ll answer this question in a minute. Plus, this article shows you how to read arbitrary files hidden in a jar file, or – more generally speaking – somewhere in the classpath. By the way, this is one of the few situations when the Junit test succeeds but the real application fails. That is interesting enough in itself.
Truth to tell, we can’t answer the question. Actually, it’s the wrong question, anyway. The real question is “Which one is better for my project?”
Because that’s what we found out during our investigation: During the last couple of years, Angular and React have learned a lot from each other. Each team is watching the progress of the other team. Good ideas tend to be adopted by the other team after a while, provided they match the general philosophy of the framework.
So we came to believe you can do anything with either framework. We’ve collected a couple of technical criteria helping you choose the right tool for the job. But you should base your decision on technical considerations alone.
Recently, I’ve been working with a project team embracing code reviews. The experience wasn’t pleasant. Most of the time, it was downright annoying.
The general idea of code reviews is that one of your team members dedicates several hours of their precious time to look at your code and help you to improve it. That’s a generous offer. Plus, hardly anybody rejects an opportunity to learn and improve their coding style. I, for one, definitely don’t. So how come the code reviews were such a pain in the ass?
Earlier this day, a developer opened a bug ticket for BootsFaces.
<b:panelGrid />, they said, is buggy. Adding a comment between the columns corrupts the layout, they said.
Actually, that’s true, but I wouldn’t call it a bug of BootsFaces. It’s a peculiarity of JSF. We could solve it in BootsFaces. At least, most of the time. I’m sure there are corner cases we’ll always miss unless we start to parse the code as thoroughly as a compiler. That’s possible, but it doesn’t match the general idea of JSF. Even worse, we can only solve the bug for BootsFaces components. It still exists for standard JSF, PrimeFaces, ButterFaces, and every other JSF framework you combine with BootsFaces. So I prefer to explain the bug instead of solving it.
At first glance, there are many similarities between Angular and JSF. Both offer a decent abstraction layer from the DOM, both offer two-way binding (yes, I know it’s optional since Angular2), and both use components as building blocks of the application. Even better, both frameworks offer a way to create your own custom components. The difference is that hardly anybody creates custom components in JSF. Angular programmers do it all the time.
Things get even more mysterious when you learn that JSF has been designed with creating components in mind. It should be easy. But the vast majority of developers doesn’t think so.
Angular takes components to a whole new level. When AngularJS 1.0 was released seven years ago (on Oct 20, 2010), that was a revolution. Developers used components all the time, no matter which framework they used. Everybody knew it’s a good idea to download or buy a powerful third-party framework. The idea was that powerful components like datatables or charts should be developed by experts.
AngularJS and its predecessors changed all that. They made the process of creating components much more democratic. They enabled everybody to create their own component. React and Angular 2+ go one step further down that road. They force every developer to write their own components. The entire program is built on custom components. There’s no way to avoid custom components.
Have you ever had the opportunity to work on a factory automation project? Currently, I’ve got the opportunity to program software controlling real hardware in an assembly line. My program influences real machines in the real world. Most of the software I’m writing remains in cyberspace, so I consider “getting real” pretty exciting.
One of the key requirements of our project is that we have to use the Modbus protocol. That’s an old protocol dating back to the 80s. Even so, I wasn’t happy with the documentation. One might expect such an old, battle-tested protocol to be thoroughly documented. Well, it is, in a sense. The only problem being that most of it has been written for experts. So I decided to write a cursory introduction for the hurried Java developer. After reading it, you should be able to understand the expert documentation. Along the way, you’ll learn something about the IoT world the media keep raving about. If you’re only interested in Modbus, just scroll to the PLC section.
Infer is a static code analysis tool promising finding many bugs that escape the attention of many other tools. My curiosity was piqued. The result was underwhelming: Infer found four possible
NullPointerExceptions in the source code of BootsFaces. Later I ran SonarQube. It found many other potential
NullPointerExceptions. Any in both cases, half of the findings where false positives.
Since version 2.0, TypeScript has a built-in NPE finder. It works very well. Of course, it sometimes finds false positives, too. But if you activate the compiler switch
--strictNullChecks from day one, that’s not a big problem because you notice the problem while you’re writing the code. You can tell the compiler to ignore the non-bug in a couple of seconds.
TypeScript 2.5 is there! That’s the headline of the tweet sending me to the TypeScript 2.5 announcment. To my surprise, the article described a new refactoring of Visual Studio Code. Did they choose the wrong title? Is this article really about TypeScript, or is it about an IDE?
As it turns out, refactoring is baked into the programming language. In former times, refactoring used to be what IDEs do. Nowadays, refactoring is a compiler feature. At least in the case of .NET languages and TypeScript.
Two weeks ago, Neil Griffin, the head of the LiferayFaces project, approached us. He asked us to do a few minor changes so the next version of Liferay and LiferayFaces can be shipped with a BootsFaces demo.
That, in itself, is quite a surprise. Liferay has finally migrated to Bootstrap 3. Obviously, BootsFaces wasn’t compatible with previous versions of Liferay. Funny thing is that at the same time the BootsFaces team discusses when it’s time to move on to Bootstrap 4. It seems the Bootstrap 3 version is going to be maintained a bit longer than expected.
So we published BootsFaces 1.1.3 quickly to align it with the Liferay release, which is expected by the end of this month (i.e. August 2017).
To my dismay, the resource ordering still causes a lot of trouble, so it’s high time to describe it in detail.
Basically, this article is simply a pointer to another article I’ve just read. In a way, we all know what happens if we discourage other people in a critical moment, but I can’t help but observe how often we ignore it. Every once in a while, I even meet team making bullying a hobby. John Looney describes the effect of such a behavior in his article. Highly recommended!
The previous article of this series explained how humans run software tests. Or rather, being an “in a nutshell” article, it gave a very brief overview. Now let’s continue the article with the testing techniques involving test automation.
The previous article in this series explained why it takes so many techniques to ensure software quality. This article explains a couple of these techniques.
When I started investigating for this article, I stumbled upon a post resonating many of my thoughts on testing. In the meantime, the post has been deleted. It has been replaced by a Youtube video that’s slightly different (probably better). Be that as it may, the original post of Itamar Turner-Trauring inspired me to draw this picture, covering most of the popular test approaches and summarizing the post.
Let’s start with the quadrant you probably don’t associate with testing. The green quadrant focuses on the user and on our customer.
Each time I write about unit testing, people get angry. So let me explain why I rant about unit tests every once in a while.
First of all, there’s nothing wrong with unit testing. That’s not the point. Usually, I start ranting when I notice people believe in unit tests religiously. Many good developers seem to believe that unit testing is the only test tool they ever need. Both agile programming and continuous delivery make us believe such a nonsense.
There’s so much more to testing than just unit tests. This post gives you a short overview about different test techniques. It’s not an in-depth explanation of these approaches to testing. Instead, it focuses on telling you why they are important. You’ll see there are many important tests that can’t be automated at all. You’ll always need human beings to test your software.
To my surprise, I saw that many people visit my website after searching for “TypeScript vs. Java”. The question makes sense, so let’s answer it. What’s the difference between the two languages? When to chose which? Do they compete at all?
At first glance, the answer is simple. TypeScript “lives” in the browser. Java lives everywhere else. So they don’t compete at all. End of the article.
However, TypeScript is an attractive language for people with a Java background. To them, the question is slightly different. Is TypeScript an easy language to learn?
Everybody knows that unit tests are valuable. So it’s a lot of fun playing Devil’s advocate as I did some time ago when I raved about the value of compiler checks for keeping up the quality of your program. So here we go: unit tests are expensive. You never know when or if they pay off.
Thing is, my experience shows that unit tests are not always good. Sometimes they even backfire. I’ve seen this in at least two projects. This time, I don’t want to talk you out of using unit tests (maybe another day), but I want to make you aware of the risks.