Altabel Group's Blog

Archive for the ‘Java’ Category

In the history of computing first Java appeared, then close on its heels came JavaScript. The names made them seem like conjoined twins newly detached, but they couldn’t be more different. One of them compiled and statically typed; the other interpreted and dynamically typed. That’s only the beginning of the technical differences between these two wildly distinct languages that have since shifted onto a collision course of sorts, thanks to Node.js.

If you’re old enough to have been around back then, you might remember Java’s early, epic peak. It left the labs, and its hype meter pinned. Everyone saw it as a revolution that would stop at nothing less than a total takeover of computing. That prediction ended up being only partially correct. Today, Java dominates Android phones, enterprise computing, and some embedded worlds like Blu-ray disks.

For all its success, though, Java never established much traction on the desktop or in the browser. People touted the power of applets and Java-based tools, but gunk always glitches up these combinations. Servers became Java’s sweet spot.

Meanwhile, what programmers initially mistook as the dumb twin has come into its own. Sure, JavaScript tagged along for a few years as HTML and the Web pulled a Borg on the world. But that changed with AJAX. Suddenly, the dumb twin had power.

Then Node.js was spawned, turning developers’ heads with its speed. Not only was JavaScript faster on the server than anyone had expected, but it was often faster than Java and other options. Its steady diet of small, quick, endless requests for data have since made Node.js more common, as Web pages have grown more dynamic.

While it may have been unthinkable 20 years ago, the quasi-twins are now locked in a battle for control of the programming world. On one side are the deep foundations of solid engineering and architecture. On the other side are simplicity and ubiquity. Will the old-school compiler-driven world of Java hold its ground, or will the speed and flexibility of Node.js help JavaScript continue to gobble up everything in its path?

Where Java wins:

1. Rock-solid foundation

I can hear the developers laughing. Some may even be dying of heart failure. Yes, Java has glitches and bugs, but relatively speaking, it’s the Rock of Gibraltar. The same faith in Node.js is many years off. In fact, it may be decades before the JavaScript crew writes nearly as many regression tests as Sun/Oracle developed to test the Java Virtual Machine. When you boot up a JVM, you get 20 years of experience from a solid curator determined to dominate the enterprise server. When you start up JavaScript, you get the work of an often cantankerous coalition that sometimes wants to collaborate and sometimes wants to use the JavaScript standard to launch passive-aggressive attacks.

2. Better IDEs

Java developers have Eclipse, NetBeans, or IntelliJ, three top-notch tools that are well-integrated with debuggers, decompilers, and servers. Each has years of development, dedicated users, and solid ecosystems filled with plug-ins.

Meanwhile, most Node.js developers type words into the command line and code into their favorite text editor. Some use Eclipse or Visual Studio, both of which support Node.js. Of course, the surge of interest in Node.js means new tools are arriving, some of which, offer intriguing approaches, but they’re still a long way from being as complete as Eclipse.

Of course, if you’re looking for an IDE that edits and juggles tools, the new tools that support Node.js are good enough. But if you ask your IDE to let you edit while you operate on the running source code like a heart surgeon slices open a chest, well, Java tools are much more powerful. It’s all there, and it’s all local.

3. Remote debugging

Java boasts incredible tools for monitoring clusters of machines. There are deep hooks into the JVM and elaborate profiling tools to help identify bottlenecks and failures. The Java enterprise stack runs some of the most sophisticated servers on the planet, and the companies that use those servers have demanded the very best in telemetry. All of these monitoring and debugging tools are quite mature and ready for you to deploy.

4. Libraries

There is a huge collection of libraries available in Java, and they offer some of the most serious work around. Text indexing tools like Lucene and computer vision toolkits like OpenCV are two examples of great open source projects that are ready to be the foundation of a serious project. There are plenty of libraries written in JavaScript and some of them are amazing, but the depth and quality of the Java code base is superior.

5. Threads

Fast code is great, but it’s usually more important that it be correct. Here is where Java’s extra features make sense.

Java’s Web servers are multithreaded. Creating multiple threads may take time and memory, but it pays off. If one thread deadlocks, the others continue. If one thread requires longer computation, the other threads aren’t starved for attention (usually).

If one Node.js request runs too slowly, everything slows down. There’s only one thread in Node.js, and it will get to your event when it’s good and ready. It may look superfast, but underneath it uses the same architecture as a one-window post office in the week before Christmas.

There have been decades of work devoted to building smart operating systems that can juggle many different processes at the same time. Why go back in time to the ’60s when computers could handle only one thread?

Where Node wins:

1. Ubiquity

Thanks to Node.js, JavaScript finds a home on the server and in the browser. Code you write for one will more than likely run the same way on both. Nothing is guaranteed in life, but this is as close as it gets in the computer business. It’s much easier to stick with JavaScript for both sides of the client/server divide than it is to write something once in Java and again in JavaScript, which you would likely need to do if you decided to move business logic you wrote in Java for the server to the browser. Or maybe the boss will insist that the logic you built for the browser be moved to the server. In either direction, Node.js and JavaScript make it much easier to migrate code.

2. Build process simplified by using same language

Complicated build tools like Ant and Maven have revolutionized Java programming. But there’s only one issue. You write the specification in XML, a data format that wasn’t designed to support programming logic. Sure, it’s relatively easy to express branching with nested tags, but there’s still something annoying about switching gears from Java to XML merely to build something.

3. Database queries

Queries for some of the newer databases, like CouchDB, are written in JavaScript. Mixing Node.js and CouchDB requires no gear-shifting, let alone any need to remember syntax differences.
Meanwhile, many Java developers use SQL. Even when they use the Java DB (formerly Derby), a database written in Java for Java developers, they write their queries in SQL. You would think they would simply call Java methods, but you’d be wrong. You have to write your database code in SQL, then let Derby parse the SQL. It’s a nice language, but it’s completely different and many development teams need different people to write SQL and Java.

4. JSON

When databases spit out answers, Java goes to elaborate lengths to turn the results into Java objects. Developers will argue for hours about POJO mappings, Hibernate, and other tools. Configuring them can take hours or even days. Eventually, the Java code gets Java objects after all of the conversion.
Many Web services and databases return data in JSON, a natural part of JavaScript. The format is now so common and useful that many Java developers use the JSON formats, so a number of good JSON parsers are available as Java libraries as well. But JSON is part of the foundation of JavaScript. You don’t need libraries. It’s all there and ready to go.

5. Speed

People love to praise the speed of Node.js. The data comes in and the answers come out like lightning. Node.js doesn’t mess around with setting up separate threads with all of the locking headaches. There’s no overhead to slow down anything. You write simple code and Node.js takes the right step as quickly as possible.

This praise comes with a caveat. Your Node.js code better be simple and it better work correctly. If it deadlocks, the entire server could lock up. Operating system developers have pulled their hair out creating safety nets that can withstand programming mistakes, but Node.js throws away these nets.

Where both win: Cross-compiling from one to the other

The debate whether to use Java or Node.js on your servers can and will go on for years. As opposed to most debates, however, we can have it both ways. Java can be cross-compiled into JavaScript. Google does this frequently with Google Web Toolkit, and some of its most popular websites have Java code running in them — Java that was translated into JavaScript.

What is your opinion on what to choose Java or Node.js?

Polina Mikhan

Polina Mikhan
Polina.Mikhan@altabel.com 
Skype ID: poly1020
Business Development Manager (LI page)
Altabel Group – Professional Software Development

The IT sector is flourishing. If you’ve used a computer for at least a couple of times in the last few years, you’ve probably noticed this. I’ve noticed it myself even more after a business trip to Stockholm where I was lucky to attend some conferences and learnt more about Swedish IT industry tendencies. These tendencies reflect our life in general. Life changes rapidly with new technologies bursting into it. And when it comes to programming languages, we get a chance to see very different trendy styles. Programming languages which were popular some years ago are not useful today. And no one can exactly predict which programming language will be popular in future. That’s why a programmer who wants to stay in developer fields has to adopt the right programming language from time to time.

As the Swedish software maker Erik Starck pointed out, “programming is about managing complexities”. And it’s really so. An understanding of at least one programming language makes an impressive addition to any CV nowadays.

It is also very difficult to get the exact number of users for any programming language. Many of us use multiple programming languages. The more experience you have, the more programming languages you use. The more programs you write or work with, the chances of using more languages rise. The larger the company, the more languages you’re likely to use.

There are a number of ways to measure the popularity of a programming language, for example, based on the number of: 1) new applications written in the language; 2) existing applications written in the language; 3) developers that use the language primarily; 4) developers that use the language ever; 5) web searches; 6) available jobs that require skills in the language; 7) developers’ favorites, etc.

My survey attempts to rank which programming languages are most popular in Sweden, each using a different measure. So, they are the following:

1) Python

Python is an object-oriented programming language which allows developers to work quickly while integrating their systems more efficiently and effectively. Designed by Guido van Rossum in 1991, Python is one of the most easy to use programming languages.

Python is characterized by its use of indentation for readability, and its encouragement for elegant code by making developers do similar things in similar ways.

Top Employers: Amazon, Dell, Google, eBay, Instagram, Yahoo

2) Java

Java is a class-based, object-oriented programming language founded by Sun Microsystems in 1995. Java is one of the most in-demand programming languages today for many reasons. First of all, it is a well-organized language with a strong library of reusable software components. Secondly, programs written in Java can run on many different computer architectures and operating systems because of the use of the JVM (Java virtual machine).

Top Employers: Amazon, Deloitte, Sun, eBay, Symantec Corporation, Cisco Systems, Samsung

3) C++

C++ is a compiled, multi-paradigm language written as an update to C in 1979 by Bjarne Stroustrup.

Due to its high-level compatibility and object-orientation, C++ is used for developing a wide-range of applications and games which makes it a popular and sought after programming language by the employers.

Top Employers: Intel, the Math Works, Microsoft, Qualcomm, Amazon, Mozilla, Adobe, Volvo

4) Ruby

Ruby is an open source, dynamic programming language designed by Yukihiro Matsumoto in 1995 with a key focus on productivity and simplicity .It is one of the most object-oriented languages in the world.

Ruby is a mix of elegant syntax which is easy to read and write and hence it has attracted many organizations and developers.

Top Employers: Spokes, VMware, Accenture, Cap Gemini, Siemens, BBC, NASA

5) JavaScript

JavaScript is an object-oriented scripting language founded in 1995 by Netscape.

Being a client-side language, it runs in the web browser on the client-side with a simplified set of commands, easier code and no need for compilation.  JavaScript is simple to learn and it is used in millions of web pages to authenticate forms, detect browsers and improve design.

Top Employers: Microsoft, Sales Force, IBM, Yahoo, Dell

6) C#

C# is a compiled, object-oriented language developed by Microsoft.

It is highly used on Windows platform and labelled as the premium language for Microsoft .NET framework. C# is known for strong typing, procedural and functional programming discipline which is the reason it has acquired so much popularity.

Top Employers: Microsoft, HP, Digi-Key Corporation, Allscripts, Intel

Those are the top 6 programming languages which are in great demand among Swedish developers.

And one more thing: remember that opinions are like noses, everyone has one and they all smell ;) If you disagree, please feel free to email me or write your own opinions in the comments.

Katerina Kviatkovskaya

Katerina Kviatkovskaya
Kate.Kviatkovskaya@altabel.com
Skype ID: kate.kviatkovskaya
Business Development Manager (LI page)
Altabel Group – Professional Software Development

Developers use JavaScript for a number of different web applications. If you continue adding more code to make it work in multiple browsers and use cases, it can quickly become a big mess. Hence you’d better use a framework to avoid this.

Frameworks like Angular, Backbone and Ember make your JavaScript code structured and keep it organized. Being all open source, they’re constantly improved by the community. They also save your time as they’re built on top of JQuery, a fast and powerful library that makes some of JavaScript’s complex operations easier to perform and more readable.

However, choosing your JavaScript framework isn’t such easy and could be challenging. Let’s try to understand how Angular, Backbone and Ember are different from each other and what their strengths and weaknesses are.

AngularJS

AngularJS is an open-source web application framework, maintained by Google and community, that assists with creating single-page applications, one-page web applications that only require HTML, CSS, and JavaScript on the client side. Its goal is to augment web applications with model–view–controller (MVC) capability, in an effort to make both development and testing easier.

AngularJS was originally developed in 2009, and it is the oldest of the three frameworks. It also has the largest community. In 2013, Angular was fourth in number of project contributors on GitHub and third in number of stars gain which testifies to its huge popularity. Moreover such well-known companies as Amazon, Google and Nike credit AngularJS as JavaScript framework. There are also a lot of news sites using AngularJS on their front pages, including the Guardian, the Huffington Post, and MSNBC. You may also check https://builtwith.angularjs.org/ to have a look at good examples of Angular apps and experiments.

Pros

  • Ideal for complex “client-side” applications, where the complexity is more in a way “components” of an application interacts with each other than in a way they synchronise and/or interact with backend
  • Very clear separation of concerns
  • Uses concepts that kind of look like the future of HTML/DOM (DOM templates, binding attributes).

Cons

  • A bit complicated to grasp. A lot of new concepts
  • jQuery or another dom parsing framework in directives may be painful to use because of the way angular compiles templates
  • Good for application with a big level of complexity on the client side, but you’ll have to learn a lot of new stuff.

On the whole, AngularJS is a robust and viable framework for building generic web apps. Whether it lives up to the expectations of being the most dominant JS framework for web development is yet to be seen.

Backbone.js

Backbone.js  is a JavaScript library with a RESTful JSON interface and is based on the model–view–presenter (MVP) application design paradigm. Backbone is known for being lightweight, as its only dependency is on one JavaScript library, Underscore.js. It is designed for developing single-page web applications and for keeping various parts of web applications (e.g. multiple clients and the server) synchronized.

Backbone came out in June 2010, and its community is nearly as large as Angular’s. Many popular applications such as Twitter, LinkedIn Mobile and Foursquare use Backbone framework. Also a number of music apps were built with Backbone, including well-known Pandora, Soundcloud and Pitchfork.

The download size of Backbone is very small compared to other frameworks which is its biggest advantage, since it only depends on one JavaScript library instead of several. Moreover, this framework is remarkably hands-off. This means experienced JavaScript developers can quickly get started. However less experienced developers might find themselves writing a lot of “boilerplate” (repetitive) code. If you’re having trouble Backbone has an especially active community rife where you could find free tutorials for getting started with the framework.

If you’re working on a single-page application or widget and you’re comfortable with being a self-starter—Backbone is likely the right choice for you.

Pros

  • Very easy to start with
  • Very small
  • Free to use any templating engine
  • A lot of excellent documentation
  • Good Community Support
  • Very popular (According to Github, Stackoverflow statistics)
  • Very flexible in how you may want to use it
  • Minimalist library
  • Easy to learn

Cons

  • No two way data-binding
  • Dependency on different frameworks like jQuery and Underscore
  • No provision for handling nested views
  • More work required to build large scale applications as compared to Angular or Ember
  • Code can become messy
  • DOM manipulations are left to the developer
  • Performs slower than AngularJS

Ember

Ember.js is an open-source client-side JavaScript web application framework based on the model-view-controller (MVC) software architectural pattern. It allows developers to create scalable single-page applications by incorporating common idioms and best practices into a framework that provides a rich object model, declarative two-way data binding, computed properties, automatically-updating templates powered by Handlebars.js, and a router for managing application state.

Ember is the newest of the three, but it’s already making waves. LivingSocial, Groupon, Zendesk, Discourse and Square are some of the most well-known applications that have adopted Ember. Ember’s creators say it’s easy to see when a site is using Ember because of its loading speed.

At 69K minified and zipped, Ember is the largest framework of the three. Ember’s larger library size partly explains why it’s the largest download of the three Javascript frameworks. Another reason for it is that Ember comes with a lot of built-in support for standard code features.

Ember’s library size and support network are its two greatest strengths, but if you’re only trying to create a small widget or single-page app, it might be overkill for you. If you’re working on a multipage, navigational, long-term project, Ember might be the right choice for you.

Pros

  • Good for long running and complex applications with deep nested view hierarchies
  • Aggregates model data changes and update the DOM late in the RunLoop
  • Well defined models and computed properties
  • Use HandleBars as templating which is flexible
  • Provides auto updating computed properties
  • Test driven

Cons

  • Relatively new framework
  • Steepest learning curve out of the three
  • Payload is the largest out of all three
  • Dependency on jQuery and Handlebars
  • Poor performance as compared to AngularJS
  • Documentation is not very good
  • Two way bindings are not implemented well

As I could see from a number of forums about JavaScript frameworks, many love AngularJS. What about you? Which one framework is your favorite one and why? Please feel free to share your thoughts/experience in the comments below :)

Yuliya Tolkach

Yuliya Tolkach
Yulia.Tolkach@altabel.com
Skype ID: yuliya_tolkach
Business Development Manager (LI page)
Altabel Group – Professional Software Development

Today comparing software on a market is a difficult task. Each product comes from a market / technology niche with great specific features developed by passionate people and open source lovers. There is no doubt the most appropriate CMS will depend on what one is trying to use it for, but let us try to have sort of a general comparison and see what definitely should be on our Java CMS shortlist.

There are so many Open Source Java CMS but let me focus on some of them which are considered quite popular now and they are Hippo, Magnolia and Jahia.

Hippo

Hippo contains an optimal combination of enterprise architecture capabilities, fast development possibilities and values of open integration. It enables you to gain the power to be open for integration with any technology that you require to manage, optimize and create high-impact customer experiences.

This CMS is really about managing content for multi-channel publication: web, mobile, social, print, etc. Separation of content from presentation is the cornerstone of the product.

Speaking of analytics systems like Webtrends, Omniture and Google Analytics Hippo CMS makes it possible for you easily embed tracking codes into content to feed analytics systems. You can also observe your content effectiveness, as Hippo exposes data collected by analytics systems in the CMS.

In terms of ecommerce, Hippo has been integrated with many custom eCommerce solutions. Take ATG, Konakart, Magento and IBM WebSphere Commerce as example. Due to the open interfaces of all Hippo components, it works whatever eCommerce system you chose.

Hippo format neutral way of managing content makes it a great source for publishing into portals. So, if your extranet or intranet runs in a portal environment, then it is not necessary to rebuild it with Hippo if you want to increase it with centrally managed content. Hippo plays nicely with all major portals and has been integrated with portals like Liferay, JBoss, SAP and Websphere Portal.

Hippo Pros:
• flexible content structure & faceted navigation
• integration with some external applications
• portal alike functionalities/ integrations
• a lot of sub-sites with sharing content capabilities

Magnolia

Magnolia powers the websites of government as well as leading Fortune 500 enterprises in more than 100 countries on all continents of the world. It is a leading CMS favored for its ease of use and license. The page editing interface enables authors to lay out content exactly as it would appear to the Web site visitor.

Magnolia is similar to Hippo in lots of ways, except that it’s very much focused on managing smaller, “single” websites. Magnolia CMS is not a framework to build web applications, however can be used to manage data. You can for instance manage products and use them as content for web pages.

Authors no longer need to switch between different navigation mechanisms to make a small change, but they can instantly edit any page in their browser.

Magnolia’s inline-editing feature ensures that editors see content paragraphs in their right context at all times, reducing the switching between working modes.

Magnolia has been designed for heavy-load enterprise websites, having a low memory footprint, a smart cache, built-in clustering capabilities, a distributed deployment architecture that decouples authoring from publishing and the possibility to build load-balanced public servers to provide more throughput and availability.

Magnolia Pros:
• good for smaller sites (content related); although, Magnolia can be used on quite big sites as well
• need in page editing/inline editing (this is possible within Hippo CMS but Magnolia is bit easier to setup)
• you only have page(content) based site/navigation. Hippo solution is much more flexible in this regard.

Jahia

Jahia delivers web content integration software by combining enterprise web content management with document and portal management features. Jahia is content centric depending on the type of project you envision, this is a major difference. The granularity of Jahia’s content model offers a deeper control on each content item. This provides greater benefit when it comes to repurposing, reusing content or controlling precisely how your content should behave (roles, workflow, layout, display options, etc.). Of course, these advantages need to be balanced with the specific objectives or your project. For a basic website scenario, this granularity is perhaps not necessary and Magnolia may be an easier choice. For intranet or portal scenarios, complex websites or content based applications, the Jahia model and its widely recognized flexibility may be more appropriate.

Jahia works great with structured content. For instance, Jahia offers options beyond the unique paragraph concept – more suited to create unstructured objects that must be displayed in a page, it offers a variety of additional objects with multiple properties you can manipulate, sort, validate, repurpose, etc. You can obviously decide to only use a simple, unstructured approach in Jahia but the ability to really declare, control and manipulate a wide range of additional object types is very powerful in more complex scenarios. Also important is that all Jahia editing UIs are auto-generated based on simple content definitions: not having to create your own input masks is a huge time saver and cuts development time.

Jahia embeds several frameworks that are very important if you plan to manipulate your content through API and code, and if you want your Jahia instance to interact with other apps / systems, some of the most important ones are) Jboss Drools, Apache Camel, jBPM.

Caching mechanisms in Jahia is based on long experience fine tuning performance for large and high traffic websites: there is a sophisticated and efficient caching solution that deals with both automatic invalidation and expiration. This allows avoiding dependencies and flushing management problems, which is key to complex, large and/or interactive sites scenarios.

Jahia Pros:
• deep control on each content item due to granularity of Jahia’s content model
• good for working with structured content
• good for large and high traffic websites

The CMSs under review have their differences but also have something in common. It might be interesting to note that all three products actually use the same storage technology: Apache Jackrabbit, which is the reference implementation of the Java Content Repository API. This ensures some guarantee as to the possibility to migrate in/out the content relatively easily.

You are welcome to make Java CMS shortlist of your choice longer with other products as well as to share your comments and comparative analysis details on the given ones. It would be really great to learn more on this subject as well as get to know your experience.

Thank you!

Aliona Kavalevich

Aliona Kavalevich
Aliona.Kavalevich@altabel.com
Skype ID: aliona_kavalevich
Business Development Manager (LI page)
Altabel Group – Professional Software Development

Some people will argue that it’s not worthy comparing Tomcat and JBoss, because one of them is a superset of the other. In fact JBoss is bundled with a forked version of Tomcat. So JBoss is Tomcat plus:

* JMS messaging provider
* Web Services engine (JAX-WS and/or JAX-RS)
* Management capabilities like JMX and a scripted administration interface
* A powerful data grid solution (Infinispan)
* Advanced security, e.g. out-of-the-box integration with 3rd party directories
* A dynamic and powerful clustering engine
* Transaction management service

Still many decision makers have to choose between these two, so lets’ take a deeper look at them.

The JBoss AS is an application server based on Java. It is an open source server and is usable in any operating system supported by Java.

Apache Tomcat, or its more widely known name Tomcat, is a servlet container (meaning it is a Java class that operates under the strictures of the Java Servlet API – a protocol by which a Java class responds to an http request). This is an open source server, providing a ‘pure Java’ HTTP web server environment in which code written in Java is capable of running.

Tomcat is only a servlet engine and JBoss offers many more functionalities out of the box. Still JBoss is no longer a heavyweight monolithic container, but a modular application server featuring true classloading isolation, modules loaded on demand, domain management and exceptionally lightweight container. It has a pluggable architecture and if required, you can unplug features from JBoss to make it essentially a Tomcat servlet container.

At the same time the plus going in favour of Tomcat is that it is fairly lightweight, and it means less memory requirement and a faster response. At the same time if you need certain JEE features beyond the Servlet API, you can easily enhance Tomcat. For example, if you need JPA features you can include Hibernate or OpenEJB and JPA works nearly out of the box.

Tomcat is hassle free and might be the right choice when you are not using much of Java features. It is a very good fit if it comes to web centric, user facing applications.

In case backend integration comes into play, a JEE application server should be considered. Last but not least, migrating a WAR developed for Tomcat to JBoss should be a 1 day exercise.

Some people still argue that instead of using application servers, one can still deliver a full stack application using Tomcat + Spring adding the right frameworks and writing the Spring integration layer with these frameworks. That’s for sure true. Still the logical question is what price you will have to pay for that. The JBoss project can be focused around average – to junior developers. Mastering the same complex stack of technologies with Tomcat and Spring requires skilled and well paid developers.

To make it short, Tomcat is merely an HTTP server and Java servlet container. JBoss is a full-blown JEE application servers, including an EJB container and all the other features of that stack. On the other hand, Tomcat has a lighter memory footprint (~60-70 MB), while JBoss weigh in at hundreds of megs. Tomcat is very popular for simple web applications, or applications using frameworks such as Spring that do not require a full JEE server. Administration of a Tomcat server is arguably easier, as there are fewer moving parts.
However, for applications that do require a full JEE stack (or at least more pieces that could easily be bolted-on to Tomcat) JBoss is one of the most popular open source offerings. JBoss has a larger and deeper user community, and a more mature codebase.

So, we should not really care anymore about which is better, but focus on the application requirements. However, you can still use the best of these two worlds in your enterprise applications.

It would be great if your could share your opinions on this topic :) Thanks in advance for your comments!

Aliona Kavalevich

Aliona Kavalevich
Aliona.Kavalevich@altabel.com
Skype ID: aliona_kavalevich
Business Development Manager (LI page)
Altabel Group – Professional Software Development

Scala is a statically typed and multi-paradigm programming language that runs on Java virtual machine and provides Java like syntax with a few improvements.

Being a multi-paradigm programming language, Scala allows for mixing multiple programming styles such as object oriented, imperative and functional programming. Whether it’s good or not, it is not a question that could be answered with a yes or no. Supporters would say that programmers can choose from a variety of styles and stick to the best depending on their needs. The others would argue that putting together some features found in many other programming languages can’t work well, mostly by increasing complexity and making a programming language obscure.

Scala code compiles to a byte code and runs on Java virtual machine, thus it is compatible with other Java applications. If most of your code and libraries are from Java world, this can be nothing but a good thing. At the same time some additional complexity in Scala is dictated by assuring compatibility with Java.

For some developers the Scala code is obscure, for others could be a nice and neat form of solving some specific problems.

One more positive aspect of Scala is its conciseness. We all know how Java verbose is and how many boiler code developers write everyday including constructors, getters, variable initialisation (type and generics), semicolons and many others.

Now let’s see some other aspects of working with Scala:

Performance
At first sight the performance in Scala is very good, comparable to Java. Scala code compiles to the same byte code as Java does and runs on the same Java virtual machine. Still how fast Scala code is may vary from case to case and usually it’s up to the way how the code is written. The awareness of how to write a high performance Scala code is especially important for Java developers who are not very experienced in both Scala and functional programming.

Tools
There are not too many development tools created specifically to serve Scala, but fortunately, thanks to compatibility with Java it doesn’t look so bad. One family of tools hardly usable in Scala are those, which do some sort of code analysis, for instance code coverage and static code analysis. Static code analysis tools are even less usable.

Language extensions
The two worth to mention native Scala extensions are Lift web framework and Akka actors platform.
The majority of libraries and frameworks from a Java world, should be possible to use quite smoothly, which among other things, is thanks to implicit conversions in Scala.

Interoperability
Interoperability between Scala and other programming languages, including Java/C/C++, is very good, mostly because of running on Java virtual machine. What Java may talk to, Scala can do as well. Taking into account support for implicit conversions described above, I would state that Scala is one of the leaders of interoperability among all programming languages.

Testing
Developers are provided with all they need to test Scala applications efficiently. To follow a Test Driven Development methodology, they can use popular in Java world Junit tool. If someone is more keen on Behaviour Driven Development then ScalaTest is a way to go.

Monitoring and maintenance
One of the main monitoring tools to analyze production Scala applications is JMX (Java Management Extensions). This tool does its job well when we want to analyse some predefined statistics, but sometimes we need to investigate some aspects of a production application while it’s running and JMX can’t provide all required data. To deal with such scenarios, Java provides Java Virtual Machine Tool Interface (JVM TI) that allows for inspecting running Java applications but it can be used for Scala too.

Support
Scala community, including forum, mailing list and blogs, is not the biggest in the world, but it’s very energetic. Most people who are part of a Scala community are very passionate developers, which are always happy to help others to solve their problems. Books are also great: Programming in Scala book by Marting Oderski, Lex Spoon and Bill Venners.

Scala skills
No one will argue that it is far behind other programming languages such as Java or C/C++. Still while looking for Scala developers we could search for Java developers with Scala interests as well. The learning curve is not massive as Scala follows Java syntax. In such case, at least on experienced Scala developer would help the team adopting new programming language.

Have you moved from Java to Scala? How do you find this language?

Thanks for sharing your opinion!

Aliona Kavalevich

Aliona Kavalevich
Aliona.Kavalevich@altabel.com
Skype ID: aliona_kavalevich
Business Development Manager (LI page)
Altabel Group – Professional Software Development

JavaScript has been popular with the developers for a number of years and has been more discussed than jQuery. However it seems to me that we should also pay attention to jQuery as, I bet, we could find a number of interesting facts about it.

Let`s start from the brief history of the two.

Initially JavaScript was called LiveScript and was invented by Netscape. In 1996 Netscape decided to change its name to raise the popularity of the language by combining it with Java. At that moment Java was used to prepare individual plug-ins. Despite the fact that JavaScript developers have tried to recreate the same syntax and functionality, as in Java, between the two languages, there are many differences. The most important difference is that the Javascript – client is an interpreted scripting language. It runs in the browser without first compilation, which is a mandatory action for programs written in Java…but it is another story.

So JavaScript is a scripting language that is mainly used for website development and client side validation.

The most common use of JavaScript is to write functions that are included in the HTML to interact with HTML elements. For example:
– Sending HTML page data to server using AJAX;
– Animating HTML element;
– Validating the HTML form;
– Storing user information that may help for Web Analytic, Ad tracking etc.

As for jQuery, when it came out in January 2006, from first sight, it looked like a cute hack and in general jQuery was seen as a passing fad. Because the chaining stuff looked like a bit gimmick and the library didn’t look like it would cover all of the bases. Still over the past months we could see that the first impression was wrong, because jQuery encapsulates an extraordinary range of common functionality, and provides a clever plugin API for any functionality not included by default. And the most important thing is that the using of the library obeys best practices and plays well with other JavaScript code.

Mostly jQuery focuses on designers and inexperienced developers, still it could be of interest to experienced programmers as well. Here I will try to enumerate the reasons why:

1) Element’s selecting. Every jQuery operation starts from selecting one or more nodes from the DOM. jQuery’s selection syntax is an interesting hybrid of CSS 1, 2, bits of CSS 3, some XPath and a few custom extensions as well.

2) Namespace. The main point in creating a good JavaScript-code for further using is carefully managed namespace. There is a single global namespace in JavaScript and many programmers clog it without any needs. More sensible developers minimize their intervention to the space using different methods. jQuery introduces the only object in the global namespace: function or object jQuery. Everything else is either direct property jQuery or a method of the object returned by a call to jQuery.

3) The $ function. You could say it is not true that that jQuery introduces only one object in the global namespace as there is also a $: the $ symbol is also set up as a shortcut for jQuery. This makes enough gently: if you want to back your former function $ (for example, if you have a piece of code based on Prototype), you can call jQuery.noConflict (), to return to his old the $. At the beginning you could considere the widespread using $ in jQuery is no more than a clever trick. But for some reason thinking of it in terms of the jQuery symbol makes everything seem a lot more sensible

4) Chaining. jQuery development team often boast about supporting this library call chains, reaching statements like «jQuery created in order to change your style of programming in JavaScript». Frankly speaking, this technique is a big turn-off than the road to the future but you can make good use of jQuery while avoiding lengthy chains of methods entirely. Briefly speaking, the chain can be used for some interesting tricks. In addition to using a set of DOM-samples you can use jQuery-end () method to move the object on the stack and exit the current context. It’s a bit hard to explain, but when you use a method that changes the current (object) context (for example, children () or filter ()), you can use the end () later to return to the previous sample.

5) Manipulating with DOM. jQuery offers a few smart ways of making large scale manipulations to the DOM. The first is quite surprising: the jQuery function can take a snippet of HTML which it will turn in to a DOM element.

6) The returned beast. Object, which is returned by the selectors jQuery, could be quite interesting. It represents a set of DOM-elements and behaves a bit like an array—it has a length property, items can be accessed by index and (most importantly) Firebug treats it as an array when displaying it in the interactive console. This is a clever illusion; the collection is actually a jQuery object, incorporating a large number of methods which can be used to query, modify and extend the collection of selected elements.

There are three principle categories of jQuery methods: those that manipulate all of the matched elements, those that return a value from the first matched object, and those that modify the selection itself. If you have Firebug you can try these out interactively: use this Insert jQuery bookmarklet first to load the jQuery library in to any page, then paste the code examples in to the Firebug console. I would like to note a convenient symmetry of these methods: they are used for display attributes (taking 2 arguments passed to or from a number of properties of the object), and to read the values of these attributes (if only one argument). This symmetry is used throughout jQuery, which greatly facilitates the storage API.

7) Unostentatious programming. The best web applications are those that can still function in disconnected scenarios, and the best method to achieve this is using JavaScript, when the events are assigned to elements only after all the HTML-page are loaded by the user. In jQuery there is excellent support for this approach. First, the paradigm of the selectors to select a node is fundamental for jQuery, and for the non-intrusive programming in general. Second, jQuery provides solutions for window.onload problems

8) jQuery and Ajax. jQuery has the best API for working with Ajax. The most simple form of an Ajax call looks like jQuery(‘div#intro’).load(‘/some/fragment.html’). This performs a GET request against /some/fragment.html and populates div#intro with the returned HTML fragment. It’s a neat shortcut, but what if you want to do something more advanced like display an Ajax loading indicator? jQuery exposes custom events (ajaxStart, ajaxComplete, ajaxError and more) for you to hook in this kind of code.

9) Extensions. Considering the whole set of features as standard, it is worth noting that uzhaty jQuery version is only 20 KB, and even less if you use archive (. Gz). Additional functionality that extends beyond this delivery can be arranged with the help of extensions that can (and do) to add new methods to an existing jQuery. If you want, you can do something like this: jQuery (‘p’). bounceAroundTheScreenAndTurnGreen(); The extension mechanism in jQuery provides documented methods for adding them to the system. Simplicity and ease of use have attracted a large community of authors such extensions, the extensions directory has more than a hundred examples. Another nice feature is the ability to add your own selectors as well as their own methods. MoreSelectors expansion adds methods like div: color (red), which, for example, selects all div with red text.

10) Several words about leaky abstractions. When studying jQuery with more respect, you could struggle with one philosophical blocker. In certain cases, jQuery uses a truly unique methods to achieve a particular function: some parts (such as source code selectors) of this library look scary. If you do so , it requires an understanding of how the library works. To understand this, you need to know some basic concepts, the differences between browsers and a set of methods, which the library uses to get around them. No library can protect you 100% against weird browser behaviour, but as long as you have a grounding in the underlying theory you should be able to figure out if a problem stems from your own code, your library or the underlying implementation.

11) Conclusion. I hope enough evidence was brought to have a positive conclusion about jQuery: it is not a regular library. It contains a lot of interesting ideas that can surprise even the most experienced JavaScript programmers and teach them something new. Even if you will not use it in the work, it is necessary to devote some time and explore the “ecosystem” jQuery.

Elvira Golyak

Elvira Golyak
Elvira.Golyak@altabel.com
Skype ID: elviragolyak
Business Development Manager (LI page)
Altabel Group – Professional Software Development


%d bloggers like this: