Open Source Yeoman generator for AngularJS Is Released by DSR

DSR understands that open source community is what pushes the modern IT world forward. DSR is well known for ZBOSS, ZigBee® open source stack certified by the ZigBee® Alliance. Moreover, DSR continuously contributes bug fixes for issues found during development with various modern development platforms and technologies.

DSR understands the value of sharing tools, standards and best practices that we use internally. So recently DSR team released a Yeoman generator for AngularJS. It has some useful optional features, like JWT support, basic components, tools for responsive UI and some others, and, of course, good documentation. The source code is available here:

https://github.com/DSRCorporation/angular-generator/

This is only the beginning. Soon we’re going to release a Yeoman generator for Node.js, several advanced AngularJS UI components and many other fancy things. Stay in touch and sign up for our newsletter to get the latest updates from DSR or check out our blog.

Developing SPA with Angular Material

Fast, convenient, tricky. These are the first three words that come to mind if someone asks how it feels to develop with Angular Material. The project’s documentation states the following right on the first page: “For developers using AngularJS, Angular Material is both a UI Component framework and a reference implementation of Google’s Material Design Specification. This project provides a set of reusable, well-tested, and accessible UI components based on Material Design.” Let’s take a close look at whether it is 100% true based on our extensive experience of developing SPAs with Angular Material here at DSR Corporation.

 Fast

Well, let’s drop all these subjective metrics and talk features:

  • Angular Material is a flex-based framework which provides an impressive set of tools to manipulate the layout. What does it give us? We can drop a huge amount of CSS purposed to position our DOM elements the way we want. Position inside a block is set with well-documented directives right in our HTML, which makes it quite easy to read.
  • Built-in nice animated dialogs.
  • Built-in services and directives to work with font-icons and SVG pictures with ability to switch between different icon sets and modify the icon style quick and painless.
  • Built-in toasts.
  • Mobile-friendly date picker.
  • Basic support of swipe actions.
  • Resource-friendly list that reuses DOM elements to render long scrollable lists in order to improve performance.
  • Built-in tooltips.

 Convenient

As its name suggests, Angular Material implements Google’s Material Design Specification. So if you want to follow Google’s guidelines you’ll find that many things work right out of the box as expected. Just keep in mind that this is one of many ways to implement it. Get ready to be flexible in your design and to alter it in favor of keeping your code clean. With great power comes great responsibility. With many built-in features, directives, services, animations, and CSS’ rules comes a hard-to-modify predefined behavior. We are not saying it’s impossible to change the way things work in Angular Material, but it would take another dirty hack to do it.

After all, convenience is a very subjective thing so here are some key features that should make your life easier:

  • Adjustable autofocus for dialogs and navigation bars
  • Beautifully animated buttons
  • Custom designed checkboxes
  • Custom designed selects
  • Built-in chips
  • Built-in complex menus and navigation bars
  • Animated input containers with support of ngMessages for error displaying and built-in text’s length counter
  • Custom designed radio buttons
  • Built-in sliders
  • Built-in switches
  • Animated tabs with custom actions on select and deselect

Tricky

Here comes a fly in the ointment. Since Angular Material is pretty young, it has all expected “puberty” problems. At the moment of writing this article it has 1545 open issues and 90 pending pull requests. That’s for a good reason: as long as it works fairly good under Chrome, it starts showing teeth under Firefox and constantly fails here and there under Safari, especially mobile Safari. If your target platform is Mac OS, you still can keep your code more or less readable, but cascade of hacks can bring your app to its knees in case you must make it work under OS X. Not to say that it’s not going to work in the end, but you will have to sacrifice some built-in features or spend hours making custom overrides, which kind of undermines the whole idea behind using Angular Material.

To sum up all of the above we can say that Angular Material is a promising powerful tool that can help you a lot and drastically improve your performance. Just keep in mind its current limitations and issues in order to not build an unmaintainable monster.

If you would like to learn more, have a project in mind, or want to share some comments, please connect with us at contact@dsr-company.com.

Hybrid Mobile Apps in the Real World

Nowadays most people have heard about hybrid mobile app frameworks and their advantages. There are so many of them and each promises everything you dreamed about for a cross-platform mobile applications development. The idea is nice and simple: hosting a web application inside of the user’s smartphone or tablet with the ability to have a single codebase, involve web developers, reduce costs, decrease time-to-market, and so on. However, we can see that most of the mobile applications are still native and platform specific. Why is that? Experienced developers (especially those who had a really hard time working with early hybrid applications) may notice that the real life cross-platform mobile app development process is far from perfect to make it a standard. DSR Corporation team has rich experience in PhoneGap application development and knows all (or almost all) pros and cons of this technology. In this blog we aim to summarize our experience and share the risks that should be considered when using a hybrid mobile app frameworks.

“Like Native” Still Doesn’t Feel Native

After your hybrid application is ready and deployed I bet the first complaint you will get is the performance. The modern day user has zero tolerance for even a slight delay, especially if he or she is expecting to be entertained. Just try to scroll a list in a native iOS application and then in a hybrid one: you will probably not say the hybrid has delays but it feels different and users notice that.

Additionally, if you want to use the same codebase for all platforms, then your application will look the same on all platforms. Sometimes it is good and desirable. Even if it is not, your application will still work fine. But as you may know the UX/UI guidelines are different for each platform and each user base has specific expectations on how apps work on their respective platforms. For example, an iOS user expects a “Back” button everywhere, where Android users may not find the search if you implement it using the iOS style. So when you are implementing the same UI, you are making a compromise or spending extra effort to make it different.

You Can’t Get Away from Debug

If it works on one platform, it does not mean it will work on another. Each hybrid app has its native part and framework development teams work hard to make them work the same way on all platforms so you could relax and concentrate on HTML, CSS, and Javascript. However, even if the framework you picked is “perfect,” each platform is assumed to have its own browser. Moreover, if you extended the native part, for example, by writing your own PhoneGap plugin, you will have to carefully port it to each platform. The situation gets more complicated when dealing with low cost or old devices: each one of them can have its own surprises. In this case you may need to research the Crosswalk pluggable webview (https://crosswalk-project.org/) to make it easier to maintain your app.

As a result, this is actually a normal case for multi-platform development when “write once, run everywhere” turns into “write once, debug everywhere.”

Platform-specific Nuances

In a perfect world a web developer can develop a cross platform mobile app without learning anything else. Meanwhile, using a hybrid framework, please make sure the team is armed with at least the following knowledge:

  • Environment configuration. At the very beginning, you can rely on a cloud build service. But sooner or later, even if you work on something simple, you will need to debug your application to make sure there will be no surprises the day before delivery.
  • Native support. It would be nice to rely on an experienced mobile application developer on your team. And it will be 100% necessary if your hybrid framework does not provide something you need.
  • Offline mode. Make sure you are developing a mobile application, not a mobile website. It will be nice if it works offline or at least provides a clear message that an Internet connection is required.
  • Guidelines. The users will very much appreciate if you meet their expectations. Everyone likes something he or she is used to and that feels natural with how they use their device.
  • Interact with others. Make sure you know and interact with typical platform applications that are used every day. Building good neighbor relationships is a good habit.
  • Deployment and approval. It can be a real pain for those who are doing it for the first time. You may need to read vendor requirements carefully even before you start the development: some rules can change your plans.

Keep it Simple

Please don’t expect too much from the hybrids. If you need something of flawless quality or great performance or exquisite look and feel – hybrid is probably not a good choice. Note that hybrid apps are fragile: the more complex architecture you have, the more effort you need to maintain it, especially if this is about interaction of HTML/Javascript part and the native part.

It’s Alive!

Considering the fact that you are still able to use native tools and controls you may think about combining web controls with native ones. Be careful not to create a Frankenstein: the application complexity can rise so significantly that it will become a nightmare to debug and maintain. First, the native control you used will need to be considered on other platforms (there is no guarantee that it will work the same way). Second, the integration part (between HTML/JS and native) is the “richest” source of bugs: the more complex the design is, the more “fun” you will have. Third, thinking about using native controls is a good signal that you need a native application. Consider your options and make the right choice for your app.

The Apple Dependency

Another risk that you may need to consider is a high dependency on the App Store Review Guidelines. The App Store is dominating the mobile apps market, so Apple can and does dictate its rules. The Review Guidelines change quite often and, although unlikely, it’s possible that hybrid apps can get banned from the App Store at some point in the future.

Now when you are aware of the risks you may wonder if there are any reasons for you to use hybrid applications. There are many of them!

Low Cost and Quick Time to Market

If you have a limited budget and need a mobile application, using a hybrid framework may be a solution. Easier UI development will give you a cost advantage even if you are planning iOS as your only platform. Make sure to keep it simple and that your single codebase can be easily ported to other platforms without significant changes. At the same time, reducing your effort can save you precious time, so you can deploy early and have the app ready before your competitors.

Startups and Explore

If you are planning to develop a serious application that requires a lot of effort for UX/UI you may consider prototyping it first. It will allow you to have better understanding of all application usage aspects and resolve problems early. Certainly, your prototype can be a quickly developed hybrid application you can use to get early adopter feedback and demo the concept.

Web Development Forces

If you or your team are good web developers, then you can use your experience in the mobile apps as well. Choose a hybrid mobile app UI framework you like the most and do the main implementation using your favorite tools. In most cases you will not need to learn a new programming language. At the same time, you will be able to develop for additional platforms improving your web development experience.

Better Than a Website

If you are thinking about developing a mobile website instead of a mobile app, then you should consider the serious advantages the mobile apps have:

  • Sales and distribution. Everyone knows about platform specific application stores that help users find what they want and allow developers to sell and distribute their apps with ease.
  • Usability. Mobile apps are optimized for use on mobile devices and users expect at least the same level of usability. It would be difficult to compete with a mobile application having only a browser application.
  • Works offline. Your users can work with the app even if the Internet connection is lost.
  • Using device capabilities. In contrast to websites, mobile apps can utilize a full set of device capabilities.
  • Popularity. Today it seems like a good habit to create a mobile app to meet user expectations.

Although we at DSR prefer to build native mobile apps because of their performance, seamless user interface, and best user experience, we have rich experience building cross-platform mobile apps as well. The latter can give you a serious advantage, but only if the related risks are considered. This is not a silver bullet, but it can be a powerful weapon on your side, if your project meets the parameters described above.

If you would like to learn more, have a project in mind, or want to share some comments, please connect with us at contact@dsr-company.com.

Why You Should Consider Node.JS as a Backend Option for Your Project

I. HISTORY OVERVIEW

In the early 2000s, when the web was small, servers were slow and client machines were even slower, developers faced the C10K problem. The problem was about concurrently handling 10,000 client connections on a single server machine. As a solution, multi-process and multi-threaded architectures (a new process or thread per each request) became very popular in mainstream software platforms for web development.

But the web continued to grow (and it still does), C10K goal became implementable on most software platforms and frameworks and the community stated the next goal – C10M problem. As you might have guessed, it’s about dealing with 10,000,000 concurrent client connections, which is a tremendous load.

The C10M problem is still relevant now and developers need new solutions to reach much higher load requirements. Most modern web apps include RESTful backend along with web and mobile apps that consume backend API. This increases load that the backend server should be able to hold.

Async I/O based platforms were created to help developers reach the goal. In this post we’ll talk specifically about Node.js as our preferred platform for high load systems development.

II. NODE.JS OVERVIEW

Node.js was initially created in 2009 by Ryan Dahl and other developers working at Joyent company (main contributor of Node.js). The idea was to use extremely fast Google V8 JavaScript engine and implement system libraries that provide common APIs which are absent in browser environments (as browsers provide sandboxes for JS code actually), like file manipulation, HTTP client/server libraries, and so on.

Because of async nature of JS (which is executed in a single thread and does not support multithreading at all), all of Node.js system libraries provide evented and asynchronous API for I/O operations, like reading a file or sending an HTTP request.

So Node.js itself might be described as an asynchronous event-driven platform. Code written by developers is executed in a single thread and, speaking of web backend development, at each moment of time only single client request is being processed, while all others are idle. However, due to the async nature of Node.js, all calls that are potentially blocking, like execution of SQL queries, have event-based API and lead to switching from current request processing to next awaiting operation (all of this is handled by the event loop).

test

III. COMPARISON WITH “CLASSICAL” SOLUTIONS

Let’s look at “classical,” thread-per-request based solutions, like Java servlet containers (Tomcat, Jetty, etc.) or Apache web server. By default, the whole thread is blocked on I/O operations here. Thus, maximum load that can be handled by a single web server instance is bounded by the maximum amount of threads that the server can handle.

Apart of the fact that creation of a new thread is relatively expensive, threads have quite a heavy footprint themselves. For example, each Java thread requires 1024KB of memory for its stack in 64-bit JVM, so 10K threads require 10Gb of RAM just for the thread stack.

So building highroad systems with such software platforms is still doable, but it’ll require many more server instances to handle the same load.

IV. OUR EXPERIENCE WITH NODE.JS

At DSR we have implemented several projects with Node.js-based backends and have been very pleased with the scalability and performance of the platform.

The strength of Node.js is the async, non-blocking I/O nature. Modern RESTful backends do a lot of I/O operations mostly, without involving heavy computations, and Node.js shines here. While reaching C10K goal requires certain effort from the developers on multi-threaded platforms, it’s just the worst performance level in case of Node.js.

Our experience confirms that Node.js is a stable and developer-friendly platform. Since Node.js 4.0, there are LTS releases now, which are stable and supported for a long period of time. As for developers, we find built-in platform tools, like npm, very handy, and, as for the code, promises cooked with generators are just simply awesome.

Of course, there are some negative points, like small amount of production-ready 3rd party libraries/frameworks. But the platform is rather young and Node.js ecosystem is rapidly growing and maturing. Growth of npm package count also indicates this well enough (see the chart below).

file

We’re actively participating in the Node.js platform community and are looking forward to building more great, high load systems using it.

Java Enterprise Development – the Technological Journey

At DSR, our expertise with Java Enterprise technologies, Java application servers, and servlets containers is often called upon by a wide array of software development projects. Our trials and tribulations in software development are many, but today we have adopted the Spring Application Framework as the DSR standard for enterprise level applications.

Let me explain why.

In the Beginning, there was Glassfish v 2.0 with SOA and ESB

In 2008, DSR was asked by the digital media industry to create a distributed solution that allowed users to work simultaneously with video editing software tools like Final Cut Pro, and a digital media archive that housed a vast amount of content.

To develop the solution, we started with Glassfish v2.0 having Service-Oriented Architecture (SOA) using the Enterprise Service Bus (ESB), and Business Process Execution Language (BPEL). DSR released several product versions and successfully supported consumers through 2012.

From an engineering point of view, we were satisfied with the technology stack but found that it was too complex of a configuration when using huge XML documents.

From a project management point of view, I believe we could have chosen better after reviewing the cost/efficiency ratio. In hindsight we realized project objectives could have been met with less engineering effort if a less complex stack would have been chosen.

Just a Few Years Ago, There was Spring, GWT, and Tomcat

In 2011, DSR was engaged to create a web-based service with stock exchange logic in the background. Taking into account our earlier learning experience with XML documents, we looked for a powerful, less complicated Java stack that allowed us to build a modern and scalable web-application.

Several server-centric technologies were tried, including, JSF (Java Server Faces) that is provided as par of Java Enterprise Application Server. However, we soon realized our approach didn’t meet the project needs for a good user experience and scalability. We quickly uncovered a client-centric technology and determined the GWT (Google Web Toolkit) showed the most promise in our tests.

For the back-end, we had to fit the integration with a relational database (MySQL or Oracle) and provide a solid infrastructure to manage the solution. After extensive research, we chose the Spring Framework in conjunction with Hibernate, and Tomcat as a servlet container.

From both an engineering and a project management standpoint, we were satisfied with the technology stack and found Spring Framework to be an integration solution that embeds the best parts of Java Enterprise libraries in tandem with a high degree of flexibility to add additional components.

Today, Evolution to Spring and Jetty

In 2012, DSR participated in developing an aircraft engineering configuration software used by workgroups. The engagement had a huge domain model (from a device down to a network package), concurrent versioning functionality with branches, dynamic ACL and rich client side UI to create and manage an Aircraft Engineering configuration.

Initially Glassfish v3 with EJB 3 was chosen for the project. Eclipse Modeling Framework was selected to deal with the domain model, while Eclipse Rich Client Platform provided a client side application. We created a custom JPA persistent provider implementation allowing for a persistent EMF based model through Hibernate. We also used a continuous integration approach based on Jenkins server.

For integration testing, we selected Arquillian technology and after six months of active development, we faced a speed issue in which our integration tests simply took too much time to execute. With a team of 10 engineers, we had several hundred integration tests with 4-hour run cycles that completely blocked our continuous integration approach. In short, our continuous integration server tested the project slower than it was developed.

While investigating solutions (including embedded Glassfish) we uncovered no viable answer. We found the issue could be solved by migrating with Spring while employing a standard Sprint testing approach. Fortunately, EJB 3 is very similar to Spring (actually EJB 3 shows a clear influence by Spring) and we only spent about 2 single-engineer work weeks to port the solution to Spring and its test approach.

Glassfish v3.0 was also replaced with Jetty since we didn’t need a Java EE server to run our server application despite us still using Java EE components. After migration, we continued to develop the solution for almost 2 years, and after successful acceptance procedures, passed the results to the customer.

To conclude, I’d say that with several years of experience using Java Enterprise technologies we have proven that the Spring Framework is a very good choice in engagements where using Java EE platform is not a strict requirement. With Spring, we have satisfied all engineering and project needs faced thus far. Despite Java Enterprise Edition being a good standardization for most popular platforms, (Glassfish and JBOSS application servers used & tested) we found Spring allowed us to provide best in class results.

Spring for a Java Enterprise level solution has become our recommendation of choice, although we remain open to support our partner’s needs and use a Java EE platform where Spring cannot be.