Embracing Redux – or What’s Wrong with Object-Oriented Programming?

Before you ask, I don’t think anything’s wrong with object-oriented programming. But recently I’ve attended an interesting talk at the JAX conference. By the look of it, the speaker, Manuel Mauky, wasn’t happy with object-oriented programming. Instead, he propagated functional programming and Redux.

While I don’t agree with him, I considered his reasoning compelling. I’ll try to summarize it as best as I can.

By definition, object-oriented programming means to combine data with algorithms. To me, this always seemed to be natural. After all, data is meaningless until you know what to do with it. From this point of view, objects join two concepts that belong naturally together.

Manuel tackles things from a different angle. He doesn’t believe that data and behavior belong together. He’s pretty much convinced that the application state should be separate from the functions defining the behavior of the application. We’ll see that this approach has many advantages.
Continue reading

Hey, We’ve Got a New Team Member!

I guess you all know the situation. One day or another, you realize that you’ve got more work than you can manage. So your boss adds a new team member to your team. It goes without saying that you embrace them full-heartedly and teach them their new job with all the respect and empathy they deserve. In virtually no time, they are just as productive as everyone else, and they become a valuable part of your team.

Or not.

It’s the “or not” part this article is about. As to my experience, many people are badly prepared for onboarding new team member. Software developers are no exception. Quite the contrary: many software developers are more interested in tech than in people, which doesn’t help to embrace new team members.

By the way, this article concentrates on software developers, but that’s mostly because I don’t want this article to be overly abstract. It’s easy to rewrite this article for almost every other job.

The good news is that almost everybody manages to wiggle their way into an existing team nonetheless. But it could be a much more pleasant experience if given more thought. And it’s simple to do it right!

What does it feel like to be a new team member?

Empathy is the word of the day. Once you start asking yourself how the new team member feels, you’ll automatically do it right. Thing is, more often than not, we’re too absent-minded to even try. Mind you, the new team member has been hired for a reason: your workload is too high to cope. Everyone has started to get edgy, and increasing the workforce is the only solution.

Here’s the catch: increasing the team size reduces the team’s productivity. If you’re lucky, that’s only a phase, but in the meantime, everybody gets beyond edgy. I’ve seen thing getting nasty at this point more than once.

Switching perspectives

You can avoid most of the trouble by switching perspectives. What does it feel like to be a new team member? Well, they enter an established team playing by rules unknown to the newbies. They don’t know much about your business. They don’t know how the established team tackles problems. Maybe they even have to learn a new programming language, a new IDE, a new framework, or whatever. More generally speaking (because it’s a problem common to every branch, not only software development): the new team members have to learn both new people and the rules of a new game. Sometimes that’s easy. Sometimes it’s quite a challenge.

Strategies

Some strategies to teach a new team member work better than others. Having them read the manual usually does not work. Telling them to browse through the wiki doesn’t work, either. It’s better to reserve three days exclusively for the rookies and to explain everything from scratch. Often it’s also a good idea to do pair programming. That, in turn, depends on the mentee. Many good developers don’t want to do pair programming. Pair programming is a skill that has to be learned, and it’s not attractive to everybody. But if you meet someone who likes the idea, do it. It’s one of the most efficient ways to bring rookies to speed. Even better: you’ll learn a lot, too.

Another good strategy is to assign bug tickets to the newbies. Solving bugs is a relatively straightforward job, but it gives them the opportunity to see many parts of the program, and to understand how everything’s glued together. After a couple of weeks assign more complex tasks to the rookie, such as developing new features. In any case, give them clear guidelines. When everything is new, it’s possible to stray off in many directions. Try to make sure that they follow the right trails instead of getting lost.

Expecting too much

Sometimes a new team member fails, and that can be quite a surprise. Even an experienced Java programmer can run into problems when joining a new team. There are many different strategies to programming. Some people prefer to test using the UI, while others prefer to write unit tests, sometimes ignoring the UI completely. Most people love their debugger, while other prefer the mainframe-style of debugging (i.e. adding log statements). Some people prefer an interactive programming style, while others prefer to start their program outside the IDE from Maven. The first group needs hot code replacement and a powerful IDE, while the latter group won’t even miss it. If you’ve learned to embrace a certain strategy and join a team using the other strategy, it’s hard to get productive. The problem is that embracing one of the strategies often makes it impossible to use the other strategy. For instance, in my former project, we couldn’t embrace the interactive programming style because hot code replacement was broken due to the project setup. Other projects can’t use the UI centric approach because their application server takes too long to start. The worst thing I’ve ever heard was an application server taking one or two hours to start the program.

So you’d rather be prepared for nasty surprises. Even experts and ace programmers run into problems every once in a while. Listen to their complaints, and try to detect warning signs as early as possible.

Gee, that new team member is so stupid!

Well, maybe the new team member is really stupid. Unlikely, but it’s not unheard of. Sooner or later you’ll meet someone who’s not up to their job. But in general, it pays to assume it’s your fault as a teacher. Be patient. Find a different angle to explain things. Don’t show your annoyance to your mentee. Adding to the mentee’s stress level only reduces their capability to learn.

By the way, the Bible calls this behavior an original sin, and it has a point. There’s a fine line between getting frustrated by lazy pupils and arrogance. Being arrogant is tackling the challenge from a completely wrong angle. Mind you: of course you have to teach the new team member even the most basic things. The established team had a lot of time to find a common consensus. The new team member doesn’t know any of the team history. That’s the definition of “new”. But usually, they are eager to help you. If you fall into the trap of arrogance, you’ll ruin exactly this eagerness. Just keep in mind you’re the ace by definition. You know everything about your project. The new team member does not. Come to think of it, it’s no surprise they act stupid. Increasing the team is not so much about you, but about embracing a new team member. On the long run, you’ll benefit from it. But you’d better prepared for a marathon than a short sprint.

Demanding too little

One of the most spectacular failures in my vocational life was when I wasn’t challenged enough. The job was simple, stupid and boring. My brain reacted by switching off altogether. So I wasn’t even up to such simple tasks like copying a pile of papers in a certain order.

In general, developing software is a demanding task, so I doubt this problem occurs very often. But even so, it may happen. If somebody fails at their job, it may be both because of demanding too much and boredom.

I can’t afford to spend time on the new team member!

Oh, yes, you can. If you really can’t, don’t hire them in the first place. Onboarding a new team member requires a lot of time. As a rule of thumb, it takes more time than expected. If you consider them as a distraction to your daily chores, you should either change your mind or communicate it to your boss early. Not everybody is interested in teaching other people. That’s OK as long as everybody knows it. But if someone chooses you as a mentor, the worst thing you can do is to chase away your mentee if they need help. If you really don’t have time to spare, politely tell them and promise to come back later.

Learn from your mentee

Teaching is one of the best opportunities to verify your ideas. If your mentee has difficulties to understand the architecture of your program, you’ve probably chosen the wrong architecture. More generally speaking, your mentee’s difficulties are always a good indicator that something’s fishy.

External consultants

External consultants are a special case. On the one hand, they are usually very experience and have seen a lot of different approaches to solving problems. On the other hand, that makes them fond of standard approaches. If a consultant tells you “it’s non-standard,” that doesn’t necessarily mean your approach is wrong. Sometimes it’s simply different. But beware: being different makes it difficult to add new team members. So this may be a good reason to listen to the consultant.

Another common mistake is to exclude the external consultant from the team. That’s just stupid. Many teams employ external consultants for months and even years. In this case, they are just another team member. Treat them as equals. If you don’t, you’ll probably ruin the consultant’s motivation and their productivity.

Anything else?

I guess there’s a lot to be added, but I’ve already stated the bottom lines:

  • Teaching a new team member is not about you. It’s about them. You’ll benefit indirectly, on the long run.
  • Teaching always takes more time than expected. Be patient.
  • Never get angry, arrogant, or something like that. Keep in mind that the new team member wants to help you. And that it’s easy to destroy their motivation.
  • Be prepared for nasty surprises. It’s always possible someone excels in one situation and fails in another. If they fail, analyze the situation and find a solution everyone’s happy with. This may include assigning that job to somebody else. This is a valid solution, but keep in mind that’s only one of several solutions.

Wrapping it up

Onboarding new team members is a complex process, involving a lot of social interaction. Don’t concentrate on the technical aspect alone. The blogosphere is full of technical discussions, but in reality, projects almost never fail because of technical issues. They always fail because people don’t collaborate.

I’m sure I’ve barely scratched the problem. What’s your experience? Feel free to leave a comment. I’m looking forward to hearing from you!

What’s New in BootsFaces 1.1.0?

Fork me on GitHubPutting it in a nutshell, the new version of BootsFaces doesn’t bring you new features. Instead, it focuses on quality and compliance with the HTML code recommended by the Bootstrap team. There’s only one new component, a few more concepts, but more than a hundred bug fixes. Granted, several of these bug fixes solve bugs introduced during the development of BootsFaces 1.1.0 itself, but even so, it’s an enormous progress. Since BootsFaces 1.0.2, we’ve committed to the core library more than 200 times, not to mention the commits to the showcase project. As it turns out, even a version introducing a single new component can be a major release.

Update May 02, 2017: Typo gremlin

Despite several weeks of testing, our good old friend, the typo gremlin, has sneaked into BootsFaces 1.1.0 again. This time, <b:form /> and the <b:growl /> are affected. We’ll publish version 1.1.1 soon, probably already this week-end.

Continue reading

BootsFaces 1.1.0 RC1

Fork me on GitHubThe next version of BootsFaces was scheduled to be published during the Easter holidays. However, we decided to spend a few extra weeks to improve the quality of the documentation of the framework. When testing the showcase, we observed that it is a bit confusing because many examples use old API fallen out of grace during the last couple of updates.

The advantage for you is that you can test the release candidate and report bugs you’ve found. We believe that the release candidate is stable enough to publish it as the final version. Nonetheless, the delay is an opportunity to fix bugs that may have slipped our tests.
Continue reading

ngx-translate and ngx-translate-extract – Internationalization Made Easy

It’s a bit surprising that there so many libraries offering internationalization for Angular applications. It’s surprising because there the Angular cookbook describes a well-thought approach to internationalization. Unfortunately, ng-xi18n was broken last time I checked, so let’s explore another library today. ngx-translate is a simple but useful library for supporting multiple languages. And ngx-translate-extract makes working with ngx-translate even easier by extracting texts to be translated automatically.

What’s the difference between ng-xi18n and ngx-translate?

Talking of ng-xi18n: there’s a big difference to ngx-translate. ng-xi18n has been developed with professional translators in mind. In particular, this library uses the well-known XLIFF standard. Developers probably tend to think this standard is clumsy. It’s XML, and it’s sort of bloated. ngx-translate, in contrast, uses slime Json file to map one language to another. The backside being it supports fewer use-cases than XLIFF.
Continue reading

Mocking HTTP Services With Angular Generically

Angular has been designed with testing and mocking in mind. This includes mocking HTTP services in general, and mocking REST services in particular. The Angular team even provides a fairly generic mock HTTP service. That service is a horn of plenty of good ideas. The only problem is the limited scope of the solution. It’s meant to serve the needs of the documentation of Angular. The team even promises that the service may break at any point in time.

In other words: it pays to implement your own generic mock HTTP service. That’s what we’ll do today.
Continue reading

UI Survey 2017: Java vs. JavaScript

Recently, I’ve seen a number of surveys covering the popularity of Java and Java UI frameworks. Most surveys show that either Spring or Java EE is more popular. However, they don’t answer two important questions: is Java becoming more or less important? Currently, I’m mostly interested in UI frameworks, so the next logical question is: what is the market share of Java UI frameworks compared to JavaScript UI frameworks?

To my disappointment, I didn’t find a clear answer, neither by researching the internet nor by asking the question on Twitter. So I’ve started to gather information myself. That wasn’t easy, so most of the article is based on indirect hints and educated guesses.

Oops!

My first surprise was when I learned about ng2-bootstrap in December 2016. At the time, Angular2 itself was still brand-new. So it won’t surprise anyone that the third-party libraries had a hard time catching up. In other words: At the time, ng2-bootstrap was a promising library, but it still had a long way to go. Compared to BootsFaces, it’s still a tiny library. In early April 2017, it consists of merely 17 components, as opposed to the 74 components of BootsFaces.

Nonetheless, ng2-bootstrap had been downloaded 70.000 times in December, give or take a few. In early April 2017, the download counter even shows 204.000 downloads per month. Compare this to 2.000+ downloads of BootsFaces per month. Oops! Such an unfinished library is 100 times more popular than the fire-proven BootsFaces?

Of course, BootsFaces is one of the smaller JSF frameworks, but even the so, ng2-bootstrap seems to be more popular than all JSF component libraries together. My curiosity was piqued.

Trendscouting

Another indicator of the popularity of a framework is Google Trends. I’ve compared the number of search requests of JSF and Spring MVC:

Comparing the Google Trends of JSF and Spring MVC
Datasource: Google Trends (www.google.com/trends)

Both frameworks seem to be roughly equally popular. JSF used to be much more popular in the past, but it has lost a lot of popularity in recent years.

Actually, the dwindling number of search requests may have a different reason. In 2004, there were three times as many search requests to JavaScript than today. But it’s unlikely JavaScript is used less today. It’s much more likely that developers ask other questions today. Or maybe they simply ask less question because they’ve learned how to work with JavaScript. The same may hold true for JSF. I’m even told JSF is gaining traction again.

Adding Angular and React to the equation

However, adding AngularJS and React.js to the trends analysis changes the image radically. There are 10 times as many search requests for React.js and 20 times as many search requests for AngularJS:

Comparing the Google Trends of Angular, React.js, JSF, and Spring MVC
Datasource: Google Trends (www.google.com/trends)

Again, that might simply mean that there are twenty times as many problems with Angular than with JSF. Plus, the search may be biased by my selection of search keywords. For instance, both Angular and JSF are “topics” of Google Trends, while React.js is categorized as a “JavaScript library”. Spring MVC is merely a search term. So it’s hard to say whether “Spring” or “Spring MVC” is the better keyword to find out about the UI framework of Spring.

Be that as it may, the trends are impressive. Plus, I’m working with Angular2+ on a daily basis. It’s a good framework, not a source of problems. Still, the huge quantity of Google searches may simply mean the developers are still learning how to use Angular. But I believe the trend also indicates that Angular and React.js are more popular than Spring MVC and JSF.

What about other frameworks?

I know that there are countless other UI frameworks, both in the Java realm and the JavaScript universe. I’ve limited my research to these four frameworks because they seem to be the most popular ones. I’ve entered quite a few other frameworks in the search bar. That didn’t change the results significantly, so I didn’t include them in the charts.

Trends of programming languages

Another indicator is the popularity of JavaScript and TypeScript. In many rankings, JavaScript, Java, and C are the most popular languages. Even if the Tiobe index indicates that JavaScript and TypeScript are much less popular than Java: Java is a general purpose language, while JavaScript and TypeScript are still being used almost exclusively in the browser. It’s possible to write server or desktop applications using JavaScript, but if I’m not mistaken, that’s still a small niche.

The last indicator is the strategy of PrimeFaces. Recently, they spend a lot of time developing the JavaScript offsprings of their JSF framework. I gather that has something to do with market shares.

Wrapping it up

For some reason, it’s hard to find information about the market share of Java and JavaScript UI libraries. Such surveys are sparse, and most of them concentrate either on Java or JavaScript. So much of this article is speculation. Nonetheless, I’m under the impression that the JavaScript UI market is five to ten times larger than the Java UI market.

Come to think of it, that’s not surprising. Java UIs are almost always used with Java back-ends. Client-side web application can be used with any back-end. That includes .NET, SAP, databases with REST APIs and even PHP. Plus, JavaScript is the language of choice for web designers.

However, I’m surprised that Angular seems to be so popular in the JavaScript world. Angular specifically targets enterprise applications, and that’s only a small fraction of the JavaScript applications. I reckon much of the rise of Angular and – to a lesser extent – React.js is at the expense of traditional server-side web frameworks.

By the way, that doesn’t affect my commitment for BootsFaces. Even if the estimated community of roughly 10.000 developers is small in comparison, that’s still the population of the village I’m living in. And it’s a lot of fun to help so many developers!

Dig deeper

Java Web Frameworks Index February 2017 by RebelLabs
Spring MVC vs. JSF
Spring MVC vs. JSF vs. Angular vs. React
License of the Google Trends screenshots

Newsflash: “Secure” in Your Browser’s URL doesn’t Always Mean “Safe”

This is a topic I consider important enough to abandon the “non-commercial-only” policy of BeyondJava.net. I hardly ever quote from or link to professional web pages unless they are so ubiquitous you can’t avoid them or there’s a good reason to do so. Web security definitely is one of the best reasons. Today, Wordfence – a professional company providing a popular WordPress security plugin – has published an interesting blog post about the green “secure” bar in your browser’s URL.

Secure vs. safe

Cutting a long story short, “secure” doesn’t mean the same as “safe”. That’s particularly annoying for Spanish and German users because these languages don’t distinguish between secure and safe. (Chances are that this holds true for many, if not most, other languages, too). Users read a green “secure” in the address bar and feel “safe”.

But in reality “secure” means that the connection between the client and the server is secure. That’s great. It means that nobody can intercept the messages and manipulate them. But that’s all it means. It does not prevent the server from being malicious.

Revoking security certificates

The good news is that when a malicious website is discovered, the certificate guaranteeing the security of the connection usually is revoked, and the server is added to a blacklist. But that takes time, and it’s not guaranteed it’ll ever happen for a particular malicious website. Plus, Wordfence reports that the revocation of a certificate does not or not always result in a red address bar. You can see the revocation, but this information is buried in the developer tools. In other words, it’s invisible to most casual users.

Stay alert!

It’s a good thing that Google has added the “secure” and “insecure” bars to the browser’s address bar, but that doesn’t mean you don’t have to be careful. Keep looking at the address bar. Keep looking for anomalies. Nowadays, fake URLs are increasingly clever, but even so, you can spot most of them if you’re alert. The Wordfence blog covers the topic in much more detail and has a few interesting examples of fake URLs.

Date Patterns Cheatsheet: Moment.js and Java’s SimpleDateFormatter

More and more projects seem to abandon Java as a front-end programming language in favor of JavaScript. Usually, they keep with Java as the backend programming language. Most of the time, both ecosystems exist peacefully. But there are sources of confusion. One of them being dates and times.

Does this sound familiar? Yes, you’re right. Dates and times are a pain point of Java since day one. JavaScript just adds another layer of complexity to this.

Moment.js is a very popular library to deal with dates and times in JavaScript. So I’ve assembled an interactive cheatsheet helping you to convert the formats into each other.
Continue reading

UI Roundup 2017: Polymer

Two years ago, Polymer looked like an equal competitor to AngularJS. At the time, it wasn’t clear which one would win the race. Truth to tell, it’s not clear today. The JavaScript world is incredibly volatile and capricious. But the numbers I collected clearly indicate Angular (nowadays without JS) is much more important. At the same time, they indicate that Polymer is here to stay.

Continue reading

Angular Takes the Sting out of Writing Components

It’s astonishing how simple writing web components is with Angular. In a way, this shouldn’t be a surprise: components are the building blocks of every Angular application. However, last week we wrote a component I already knew to be difficult to implement in merely an hour or two. That was really a surprise.

Our choice was a multi-choice select box. There are plenty finished components out there. However, Angular 2+ is still young, so there are few (if any) native Angular multiple-choice boxes we can use. Integrating a component based on other technologies like jQuery is possible, but usually, it takes some time and it’s always a compromise. So I reluctantly agreed when my co-worker suggested to quickly write our own component. “It’s simple”, he said. “It ain’t much work”. It’s true. It wasn’t.

Key to success: template language

The key to success is the clever template language of Angular. More often than not, I’m unhappy with template languages because they always feel clumsy. Angular’s template language doesn’t. Of course, that’s simple because it doesn’t aim to be a general-purpose language. It’s been written specifically for a single purpose, and it serves this purpose well.

I don’t have the source code at hand, so let me sketch our source code from memory. The multiple-choice combobox consists of an input field, which is always visible, and a pane containing the options. The pane is hidden most of the time. So the HTML code (or rather: pseudocode) looks like so:

<input [(ngModel)]="selectedValues" 
       (onfocus)="optionsVisible=true"
       (onblur)="optionsVisible=false">
<div [attrs.visible]="optionsVisible">
  <div class="checkbox" *ngFor="let option in options">
    <label>
      <input type="checkbox" [(ngModel)]="option.selected"
             onchange="updateResult()"> 
      {{option.value}}
    </label>
  </div>
</div>

This little snippet reads and writes like plain vanilla code. But in reality, it’s revolutionary. It takes a lot more code in Java to write an equivalent JSF component. I also compared this code to my AngularPrime/Dart framework I wrote a couple of years ago. Dart is a fine language, but it took much more time and effort to write a simple component.

The component class

Of course, the HTML code is useless without the TypeScript glue code. But again, this code is fairly straight-forward. The sketchy pseudocode looks like this:

export class Option {
  label: string
  selected: boolean = false
}

@Component({
  selector: "multiple-choice",
  templateUrl: "multple-choice.html"})
export class MultipleChoice {
  @Input() options: Options[]

  @Output() result = new EventEmitter(string)

  optionsVisible: boolean = false

  updateResult(): void {
    let result = options.filter(option => option.selected).
             reduce((option, previous) => previous + "," + option.label, "")
    result.emit(result)
  }
}

Another key to success: @Input and @Output

We’re almost there! All we need to add is a little CSS file to arrange the panel properly below the input field. Everything else is handled by Angular: we can pass the list of options to the component using the @Input decorator, and @Output sends the result to the outer component:

<multiple-choice [options]="colors" 
                 (result)="setSelectedColors($event)">
</multiple-choice>

Wrapping it up

Of course, I’ve omitted some details to keep things simple, and I’ve shown only pseudocode. But even the real source code is surprisingly simple. Angular focuses on writing components. Therefore, it makes writing components as simple as possible without sacrificing power. I had the opportunity to compare different approaches, and I’m astonished by the ease of use of Angular.

Newsflash: Saving HTML Pages or Snippets as an Image

There’s a nice JavaScript project allowing you to save HTML snippets as an image. I didn’t test it yet, but the Fiddles look nice (for instance, this one).

Basically, the library traverses the DOM, using an HTML5 canvas to draw the elements it finds. In other words, it’s an HTLM rendering engine written in JavaScript. Most likely, that means that the library only supports a small fraction of the giant set of HTML attributes and elements. But still, it seems to support many common use cases.

Another approach is putting foreign objects into an SVG and to draw that SVG image into an HTML5 canvas. The foreignObject is currently only partially supported by most browsers, but even so it seems to do the trick for many common usecases.

The Dark Path?

It always pays to listen to Uncle Bob Martin. He’s clearly someone who’s got something to say. But that doesn’t mean I always agree. Today, I don’t. And I consider it interesting why we disagree.

I’ve just read Robert Martin’s post“The Dark Path”. He picks three innovative traits of Kotlin and Swift: strict null checks, strict exception handling and making classes final (in Java speech) or closed (in Kotlin lingo) by default. It’s an interesting post I recommend to read. Uncle Bob shortly explains these features, continues with complaining about languages becoming too complex because they try to fill each leak of their predecessor languages, and closes with an ardent call to write tests. Like usual, he arguments very convincingly. It’s hard to disagree after reading the article. Yet I do.
Continue reading

How to Use a JavaScript DataTable in an Angular Application

Fork me on GitHubThere are several data table widgets for Angular, but none of them matched our project’s needs. I’m sure that’s simply a matter of time. Angular2 is young, and the third-party libraries are even younger. They simply didn’t have enough time to accumulate features and maturity. So why don’t we use one of the seasoned JavaScript data tables?

As it turns out, Louis Lin had the same idea creating the Angular DataTables project. It looks promising, but at the time of writing, it was only 26 days old. So the feature list is pretty short. When you’re reading this article, things have probably improved. However, today I don’t want to tell you how to use a third-party data table. Instead, I’ll tell you how to do it yourself. Before we start to wallow in the source code, let’s start with what developers usually do: a short market survey. If you’re in a hurry, skip that section or jump directly to the source code of the demo on GitHub.
Continue reading

Charts with Angular: ngx-charts (Formerly: ng2d3)

Originally, I wanted to write an article about ng2d3. That’s a fine library bringing the power of D3.js charts to the Angular2 world without the price. D3 requires you to adopt a special programming style. You have to learn and use a new programming paradigm, the data-driven programming style. ng2d3 doesn’t require such a thing. You just pass it the data, and it’ll draw the diagram for you.

The only problem with ng2d3 is that it doesn’t exist anymore. More precisely, when I started writing, the team published a new major version (including a couple of breaking changes) and changed the name of the project. Now it’s called ngx-charts. In the view of the new semantic versioning strategy of Angular, the name makes a lot of sense. Calling a framework “ng2-something” won’t work when Angular4 will have been published, skipping Angular3 altogether.
Continue reading

How to Use BootsFaces and PrimeFaces in the Same Project

I’ve always promoted BootsFaces as a companion framework for PrimeFaces, but many developers report it’s difficult, if not impossible, to combine these two frameworks. Things are particularly nasty if you’ve already got a (possibly huge) PrimeFaces application. Some developers report that even adding a single BootsFaces component will distort your application’s layout. So I’ve decided to examine the problem more closely and to do something about it. This article sketches how to integrate BootsFaces components into a PrimeFaces application. I’ve also created a project at GitHub demonstrating the idea. Note that this article doesn’t show how to use a PrimeFaces component in a BootsFaces application. Of course, that’s almost the same problem, but the source codes below only consider the first use case.
Continue reading

What’s New in BootsFaces 1.0?

Fork me on GitHubBootsFaces 1.0 has been released. Actually, we’ve already published the first bugfix release, BootsFaces 1.0.1. I was a bit shy to proudly announce the 1.0.0 version because we had so many obstacles to overcome. Apart from the usual obstacles like exhausting projects at work (and they were exhausting this time!), there were also the earthquakes in Italy, which kept at least one of our team members busy, although they didn’t suffer any physical harm.

Be that as it may, BootsFaces 1.0 (and 1.0.1 in particular) is a great step to maturity. It’s the first version we officially call “production-ready”. Truth to tell, we were always convinced you can safely use BootsFaces in production. But most versions we’ve published in the past focused on features. This time we tried to focus on stability instead of new features when we prepared the 1.0 version. I counted 26 bugfixes that were important enough to open a bug ticket. Plus, almost twenty minor enhancements and three new components. However, we also added one or two major improvements, such as adding support for both horizontal and inline forms.

Download coordinates

Before starting the long list of details, let me provide you with the download coordinates:

Add these lines to your project’s pom.xml:

<dependency>
    <groupId>net.bootsfaces</groupId>
    <artifactId>bootsfaces</artifactId>
    <version>1.0.1</version>
    <scope>compile</scope>
</dependency>

Add this line to your project’s .gradle build file:

compile 'net.bootsfaces:bootsfaces:1.0.1'

The BootsFaces project comes with both a Gradle build file and a Maven build file. The Maven pom.xml is the easy way to get started and should suffice for most purposes. Only if you want to tweak and optimize BootsFaces, you need the Gradle build. In particular, the Maven build doesn’t generate the CSS and JS files itself, but relies on the output of the Gradle build. By the way, that’s the reason why we keep the generated file in GitHub.

In any case, the URL of the repository is https://github.com/TheCoder4eu/BootsFaces-OSP.

Update Dec 27, 2016: Bugs

During the last couple of days, we’ve found and fixed a couple of bugs. If you happen to run into a bug, check our bug tracker if we’ve already solved the bug, and check out the sneak preview version of BootsFaces 1.1.0-SNAPSHOT. Strictly speaking, this version is not intended to use productively. Use at own risk. Of course, BootsFaces is published under an Apache V2 license, so every version of BootsFaces is published on an “as-is” basis, without any warranties. The difference between the snapshot and the final version is that we’ve tested the final version more intensively.

Continue reading

How to Connect HTML Elements With an Arrow Using SVG

The other day, had a list of items on the left-hand side, and another list of items on the right-hand side. Some of these items are connected, some of them are not. Wouldn’t it be nice to show this by connecting the item with an arrow?

At first, there’s nothing new here. We’ve been drawing and connecting boxes, circles and arbitrary shapes in the IT business for ages. Just think of flow charts or organigrams. There’s even a nice PrimeFaces component for that.

The problem is that my application was an Angular2 application, not a JSF application. Plus, the PrimeFaces component, which is really nice, didn’t match my requirements. I didn’t want to display a flow chart. The boxes I wanted to connect contain live data and even images. So the task is to connect arbitrary <div /> elements with an arrow.

At first, the task seems a bit intimidating, but once I’ve started to delve into it, it became surprisingly simple. Simple enough I can even provide the source code at the end of the post.
Continue reading

Electron Brings JavaScript to the Desktop

Let’s continue my “Java on the desktop” series with something that’s not Java, but interesting nonetheless. Electron is a framework wrapping your HTML5 application in a native window of your operation system. Other than most projects in the JavaScript universe, Electron does not follow a “mobile first” approach. Quite the contrary, it’s fairly opinionated in that it supports only three platforms: Windows, OSX, and Linux. This includes access to your computers file system and access to the Windows registry via third-party NPM modules. If I’ve got it right, it even allows you to install your application as a Windows service, which is kind of scary. You know, not too long ago every security expert recommended deactivating JavaScript in the browser because of alleged security risks. Obviously, we’ve come a long way.
Continue reading

How to Wrap BootsFaces (or JSF in General) as a Native Desktop Application

When I showed the draft of my last post (the “Java on the Desktop” survey article), my friends surprised me by saying that nowadays desktop applications are sort of exotic. Everybody’s doing mobile or at least web applications. But the good old desktop has fallen into oblivion. That’s pretty strange, given that most of us do most of their daily work at desktop PCs or decent-sized laptops.
Continue reading