Archive for July 2013
Ruby is a dynamic programming language that gains popularity year by year due to its simple syntax and effectiveness. There are many web frameworks written in Ruby. I’m pretty sure everybody heard of Ruby on Rails, but are there any other Ruby frameworks deserving attention and offering better options than Ruby on Rails does? With the success of Ruby on Rails, is there a place left for other web frameworks written in Ruby?
Most Ruby developers are working with Ruby on Rails for building web applications. However, there are some great alternative frameworks out there that also deserve a look. Some of these frameworks borrow heavily from Ruby’s premier web framework. Many offer significant improvements in speed and flexibility. Some can be used as outright replacements for Ruby on Rails. Others are perfect for running as supplemental services, when something faster and closer to the metal is needed. And a few have entirely different goals in mind, such as providing a whole web application stack in a single file for easily deployed mini-applications. But despite all their differences each of these frameworks has at least two things in common: a great dynamically-typed human-friendly base language-Ruby-and a smart, enthusiastic core group of contributors.
Here is an overview of some Ruby web frameworks which deserve a look. Let’s see how they are similar to/different from its most popular representative-Ruby on Rails.
1. Ruby on Rails
As it was already mentioned, Ruby on Rails (sometimes known as “RoR” or just “Rails”) is perhaps the most popular Ruby framework that is in use today, and with good reason. Ruby on Rails was the framework that popularized the MVC approach. This is done primarily by the Ruby on Rails MVC framework that consists of the Model (ActiveRecord), View (ActionView) and Controller (ActionController) sub-systems. It is open source and comes with a rich set of features including: AJAX support; a host of testing, security, caching and form-validation frameworks; internalization and localization functionality; and there are also pretty standard features such as DB migration frameworks, MVC Push capability, etc. Ruby on Rails emphasizes agile development, “Convention over Configuration” – developer only needs to concentrate on the non-conventional aspects of application development, and “Don’t Repeat Yourself” – information is located in a single, unambiguous place. Since it has been around for a while, there is a well-defined API, extensive documentation as well as tutorials all over the web and finally a vibrant and supportive community. The principle difference between Ruby on Rails and other frameworks for development lies in the speed and ease of use, so developers working within the environment really enjoy it. Changes made to applications are immediately applied, avoiding the time consuming steps normally associated with web development cycle.
At less than 4kb code size, Camping is one of the lightest Ruby frameworks around. In fact, it is one of the developers’ stated goals to always keep it below 4kb code size. It once again follows the MVC philosophy and provides a single file in which to carry out the development of the entire application , although the separation between each sub-system is still maintained. The developers also suggest that once initial or prototype development is completed in Camping, the project can easily be migrated to Ruby on Rails. So in some cases Camping is a precursory development environment for Ruby on Rails.
Camping does not have AJAX support, internalization and localization frameworks, nor security, caching and form-validation frameworks, but has pretty much other necessary functionality such as DB migration, Testing frameworks, ORM, etc.
Nitro is actually a framework that was around before Ruby on Rails became popular. There are a number of web developers who still swear by it. One of its finest features is a powerful template system that has a pipeline of configurable transformation steps. It is open source and along with the template style programming, there is the option of using the MVC approach as well.
Ramaze is a very simple and straight-forward web-framework. Its emphasis is on simplicity. Ramaze also has a strict adherence to modular design and having minimal dependencies between different modules. Ramaze comes with a templating system called Ezamar and also has a fairly full-featured support for MVC applications.
Sinatra is a Ruby framework which like Camping is perhaps more suited for prototype development than actual business applications. It does, however, have a pretty standard set of features including MVC support, DB migration, Template and Caching frameworks. It does not have AJAX support, nor security and form-validation frameworks. A recent entry into the Ruby web framework space, Sinatra is designed as a minimalist RESTful framework that sits on top of Mongrel. It’s core is a simple domain specific language for defining RESTful actions and responses. Also ideal for single-file mini-applications; ORM agnostic and built on Rack.
Halcyon is another lightweight framework built on Rack for speed and light weight. It aims to provide a framework for developing service-oriented applications (SOAs) such as APIs or other non-interfaced services. It has AJAX support through the JSON interface, and overall is a very well documented project and has a strong support community.
Waves seeks to provide an alternative solution for applications that do not need an MVC architecture. Thus, it has support for such things as AJAX, Adobe Air, mashups, OpenID, rich-client mobile apps, etc. This is done through a rich DSL. Waves’ developer speaks of the concept of request lambdas which are basically request mapping into a certain block, which results in a certain level of flexibility by removing some of the responsibilities of the Controller and placing the emphasis more on mappings. However, note that this is a subtle or implicit modification to the MVC pattern, and so it’s better to use it only after you have a good grasp of what’s going on and are confident that this is exactly what you need.
As you can see there are a large number of frameworks for writing Ruby web applications instead of using Rails. Rails is absolutely a great framework but it’s always good to have other tools at our disposal, isn’t it? Maybe some smaller job or certain features of any of these frameworks would be better suited to the task. Having this variety of web frameworks is healthy for the Ruby community as it not only gives developers options but also allows for exploration of innovative ideas that may not be implemented with Rails. Check one of them out if you have the opportunity – I’m sure you won’t regret this. Please note that the list of Ruby frameworks in my article wasn’t intended to be exhaustive. If I am missing some frameworks, please let me know and I will incorporate them into future posts. As always, eager to see your comments 🙂
Today I would like to draw your attention towards Business viewpoint in comparison of SharePoint and Drupal.
So let the story begin.
Initially SharePoint was created as a document management system and has over time, through continuous expansion and new features, taken on some similarity to a content management system. So for today SharePoint is being positioned as not only an intranet platform, but also a web framework that can power big sites and be on the same playing field as other larger CMS platforms. Drupal in its turn has been developed to provide the foundation to build something, whether it’s a corporate website, web-shop, customer portal, CRM, intranet or extranet, or all at once. So theoretically, we can admit that since then, Drupal and SharePoint has seen the light, both platforms have been more in each other’s way and the debate of Drupal vs. SharePoint has been part of their history. Still what is a wiser choice?
Time for setup
In this point Drupal knock SharePoint out. Firstly Drupal is based on PHP that makes it very easy to run on any environment. With SharePoint, it needs to run Windows locally to be able to set up even the development environment. If you do not have Windows, you will need run it on VMware or other virtualization software. In this case you will have to beef up your local machine to manage the memory requirements.
Today SharePoint Online definitely obviates the set up hassle for companies not looking for self-hosted solutions. Even so, the configuration steps are not as easy and shiny as they might look on the surface.
Drupal allows to quickly set up an intranet site or something on a public domain in a few hours. From a business point of view, you can get rolling within a few hours!
Integration with other services
In this case SharePoint definitely has serious advantage of how well it integrates with the other Microsoft services. So, if as a company you are invested in Microsoft and its other services, SharePoint is a natural choice. Firstly, you would already have Windows developers and system administrators and secondly, the tight coupling SharePoint offers with other MS services is golden.
Though Drupal can be configured to interact with other MS services, it is much easier in a non-Windows scenario.
While SharePoint solution need to have not only developers but an in-house SharePoint system administrator to be able to carry out deployments, Drupal does not required any extra developer or CPU resources.
Activities beyond intranet
One of the claims of SharePoint is how it helps companies launch multiple websites apart from just setting up an intranet platform. Still to pull this off it requires a humongous number of human resource and the technical ability . The same can be achieved with Drupal but easier.
Maintenance against paid upgrades
SharePoint today is in a much better shape than what it was a few years ago. But the progres has been very slow and every upgrade means digging deeper into your pockets.
With the community based model, Drupal has seen a far better progress in a much shorter time. The progress has not just been in the core platform but also the kind of plugins and extensions for rapid site assembly available to make Drupal a fuller platform.
In the market Drupal being an open source option has a lot of low cost and free available themes, that can be integrated without much effort. SharePoint in its turn charges for the themes and plus designers have to know XSL to be able to tweak the themes.
What do you think who will have more advantages if we compare an open source option with a Microsoft product? JStill it’s important to note that, SharePoint as an online hosted solution is much more affordable than its predecessor downloadable versions. The licensing fee and the developer licenses were prohibitively high which now can be circumvented by going for the online versions.
From business point of view open sourсe solution seems more profitably than corporate one and Drupal wins. Still if we compare them from technical point of view…who knows, may be the Microsoft’s family product will gain revenge. It would be interesting to know your thoughts about it.
Zend Framework and Yii Framework are object oriented web application frameworks written in PHP. Over the recent years Yii has become extremely popular with the developers for implementing large scale secure and fast web applications, better to say, has become number 1 choice for many of them. However with the long-awaited release of Zend Framework 2 (ZF2) that supports all great PHP 5.4 features the position of Yii may sufferJ
So let`s start with the “newborn” Zend Framework 2. In no way it can`t be compared with the older ZF versions as ZF has been totally rewritten. More than 5 years have passed since ZF 1.0.0 release! Zend framework 2 includes almost all the advance PHP features which have taken the framework to the next level.
Some of the great features:
Service Manager. It`s one of the best features of ZF2. Service manager is simply a layer which will return you the object of any service you want to use in your application with the flexibility to include your own factories.
Event Manager. The basic architecture allows you to attach and detach listeners to named events, both on a per-instance basis as well as via shared collections; trigger events; and interrupt execution of listeners.
PHP Composer. Another great addition in the ZF2 which will automatically get the dependences of the project groom is the PHP composer. Composer makes sure that every project is using the same libraries with same versions.
Some developers may call it over engineered as the learning curve of the framework is quite hard. Also documentation is currently the weakest part of ZF2: Zend has followed its tradition of bad documentation. However the Zend skeleton application tutorial may provide you with some info about the framework.
And now let`s move to YiiJ Yii is a component-based high-performance PHP framework for developing large-scale web applications. We have already had a couple of articles in our blog dedicated to this frameworkJ To cut the story short , Yii is very fast and flexible and has many pluses and great features. Here are some of them
Yii Community. It is very vibrant and active and its participants can render great assistance to every developer.
Gii Module. Yii has handy built-in code generator Gii. With its help it`s possible to create web 2.0 applications in minutes. Basically this module allows you to create a model from your database table and then can from that model you can create the CRUD operations.
Active Record. One of the pluses is comfortable work with database: it can be used either as Data Access Objects, or as Active Record
Among the downsides of the framework many developers name a quite tough learning curve. Besides while using YIi developers need to be very careful about what you are dealing with, if you can do it well you are good to go.
Have you already tried to work with Zend Framework 2? Would you prefer ZF2 or Yii for your projects? Interesting to know your thoughts.
Many companies seek to expand their business and provide software products for the worldwide market through localization (L10N) — translating or adapting a software product into different languages or for a specific country or region. Many localization attempts are met with frustration once the software is built: Text is garbled, fonts aren’t exact, encoding of exotic languages doesn’t look right, sentences are cut off, and in general, software builds may not work as designed.
Here are some pointers to help you avoid these problems and produce a quality product for the global market.
1. Plan ahead
For many companies, software localization turns out to be a last-minute rush before a product release. All localization scheduling and scoping efforts should take into account the translation, testing, and regression that must occur to produce a quality product.
2. Test your software
In most cases, localized software should be tested as rigorously as the original English software. There’s no replacement for the awareness that comes with seeing a foreign language “in context” within your software.
3. Develop a detailed English test plan
Use this same test plan in your localized testing. The same crucial UI dialogs and functionality will be put to the test. Reusing the English test plan for localization testing is common in the industry and will avoid delays in L10N testing.
4. Leave plenty of space for text expansion in other languages
Many languages take up to 30 percent more space than English! If your engineers design the software for which English “just barely fits,” you’ll have a problem down the road. Leave ample space or program dynamic UI expansion into your software.
5. Use localization-friendly encoding of strings
When possible, source your string tables or software resources in Unicode/UTF-8 encoding. This will avoid extra conversion steps, time-consuming debug work, and garbled text.
6. Perform “pseudo localization” to root out hard-coded strings
In a separate temporary branch, use a regular expression to replace all letters in the string text with a single repeating character, such as “XXXXX.” Build the software, and any hard-coded text will really jump out at you, showing string IDs that are not defined in string tables.
7. Avoid concatenation and overuse of single strings
A combination of words in English will most likely not follow the same order in most other languages. Concatenated strings and strings that are used in multiple contexts will have grammar and gender agreement issues. Gone are the days of optimizing software due to memory limitations, so be generous when localizing your product.
8. Provide “internationalization” support in your software (i18n)
This will enable dates, numbers, and other region-specific data such as currency to show up in a familiar and comfortable way to all users around the world.
9. Provide numerous comments in software resources that define context
Knowing the context and use of certain strings will help translators choose the right translation from the beginning. Most translation tools will allow translators to see these comments as they translate the strings.
10. Perform localization of Help and software (GUI) at the same time
Users around the world will notice when context-sensitive help tells them to click on a button that is worded differently in the software itself. Seek a responsible and experienced translation company to handle both your software and Help/User’s Guide at the same time to ensure consistency between your software and help documentation.
Localizing your software can be an exercise in frustration. Hope you’ll avoid major headaches by following this practical advice.
The beauty of Internet-enabled applications is that it’s easy to add value with rich media, real-time monitoring, and other features. But with this flexibility comes new responsibilities for testing the “goodness” of applications in real-time situations. For instance, if employees are using mobile devices powered by Internet, app developers can no longer assume a stable in-office environment in which their applications will be used. Instead, they might have to consider whether an app will be used in a moving car, or in temperatures below freezing. This conflicts with present IT application testing methodology, which usually doesn’t go far enough to test for environmentals and usability. As a result, IT can miss the boat in its testing strategy and find itself doing much more work in app maintenance.
Here are 10 things to consider if you are developing apps that have to function with outside “things,” –environments and usability challenges that you can’t readily foresee in your test lab.
1. Think about how people will use the application
An application that comes packaged on a consumer-grade laptop or notebook for a police squad car will not withstand the rigors of high-speed chases and constant bangs and knocks. Part of the application testing strategy, if you are developing for situations like this, should include the testing of the robustness of the device itself in adverse operating conditions. If you fail to include the device in your test plan, the app might be great — but it might also crash at a critical moment if the end device fails.
2. Consider environmental conditions
It doesn’t do anyone any good if an end user tries to place a consumer-grade device in a freezer to monitor temperatures. Ruggedized handheld devices are especially designed for work in extreme cold conditions. This is a case where it is important to know the environments that users are going to use their mobile devices in — which again, makes it essential to include the device as well as the app in your test plan.
3. Develop a comprehensive test plan with a checklist for usability as well as for app features and functions
Eighty percent of end user acceptance of an app comes down to usability (over features and functions). Yet interestingly, an IT test plan is usually the reverse (80 percent features/functions and 20 percent usability). I once redesigned an app that had been sitting on the shelf at a company for more than two years because it had an unfriendly user interface. Once we pared away two-thirds of the interface (and reduced the features-functions set to make the app less complex), the uptake by users was almost immediate.
4. Actively engage users in testing
Engaging users in testing (especially for usability and fit for environment) ensures that there are no surprises from the user side when the app goes into production. It also ensures user signoff and buy-in for the app and an ongoing collaborative relationship with the end business unit as you enhance the app over time.
5. Engage users up front in app design
Many IT application developers now get users involved at the very beginning of application design, especially when it comes to designing the application interface. It’s a good practice, because it provides a working blueprint of user interface requirements that your test plan can be linked into. It also puts the users (and not IT) in charge of designing the “look” of the app.
As soon as developers have a working model of an app, they should sit down with end users and demonstrate both the user interface and how data flows into and out of the interface. These demo sessions should be short and iterative (as more pieces of the app are completed), and they should occur often. Doing this will ensure that the app continues to track true to user requirements. These regular prototype reviews will significantly shorten QA and final test times.
7. Build scalability into your app — and test for it
Especially for Internet and mobile devices, app add-ons such as rich media should be anticipated to grow. Your design plan should anticipate this (e.g., scalability for storage, CPU, bandwidth) — and your test plan should test for it. By sizing for future expansion, you can avoid costly app redesign.
8. Include security and lockdown
Data encryption, conformance with security standards, and locate and lockdown ability when devices get lost are all important test points for mobile devices. IT usually gets the first two, but the locate and lockdown is often missed. It shouldn’t be. Thirty billion dollars worth of mobile devices were lost last year.
9. Use standard APIs for app interfaces
One of the worst nightmares for application integration (and almost all apps are integrated with various data repositories, other apps, etc.) is the development of custom interfaces that have to be changed over time — and which in turn create maintenance work on every other app they touch. You can save a lot of time in regression testing by sticking with standard APIs.
10. Make testing everybody’s business
We’ve already talked about getting end users engaged in final checkout and in intermediate checkouts. But it’s also good to include input (and checkout) from the help desk, which understands as well as anyone in IT what the constant user pain points are. It’s also a good idea to split your QA team into two camps: one side that tests the app for technical “goodness” and a second side that tests for usability and overall “fit” for the business and the end user’s work environment.