If Chuck Norris Were A Programmer

Top Ten “If Chuck Norris Were A Programmer” Jokes

10.          If Chuck Norris were a programmer, memory would be afraid to take a leak.

9.            If Chuck Norris were a programmer, President Obama would be doing his garbage collection.

8.            If Chuck Norris were a programmer, the food chain would collapse because he would kill every bug on the planet.

7.            If Chuck Norris were a programmer, unstructured data would become structured. With Chuck around, nobody ever gets out of line.

6.            If Chuck Norris were a programmer, application security wouldn’t even be an issue.

5.            If Chuck Norris were a programmer, all his programs would be strongly typed.

4.            If Chuck Norris were a programmer, none of his functions would have arguments.

3.            If Chuck Norris were a programmer, his first program wouldn’t be ‘Hello World’ it would be ‘Goodbye Underworld.’

2.            If Chuck Norris were a programmer, there would be no exception handling, because there would be no exceptions ever.

… and the Number One “If Chuck Norris Were A Programmer” Joke:

1.            If Chuck Norris were a programmer, all his applications would be perfectly metadata-driven. After all, they would be developed on a Magic application platform! 

A Trip to the .NET Forms Library with uniPaaS 2.0

With the release of uniPaaS 2.0, the Magic Application Platform now supports the use of the Windows .NET forms library. These capabilities are delivered by .NET within “classes” that are a part of what is known as the System.Windows.Forms namespace.

Beginning with uniPaaS 2.0, the use of the .NET Forms library within a uniPaaS application is supported in both uniPaaS online (client server) and rich client tasks. After you begin a new task, you must define your .NET object in a new variable by creating a virtual variable in the Dataview Tab of the uniPaaS task. You select the .NET object type either by typing the name or using the uniPaaS selection lists to find the .NET object you want to use.

Developing with the Windows .NET forms library is much easier on the uniPaaS .NET application platform than it is in simple 3GL .NET coding languages such as C#, C++, JScript or VB.NET. uniPaaS 2.0 provides a metadata driven paradigm for application development that allows you to easily incorporate managed code from the .NET forms library along with so-called “unmanaged functionality.” This is true because the uniPaaS 2.x runtime engine is an extension of the uniPaaS 1.x runtime engine. A new .NET front-end wraps the existing C++ engine, thus enabling both .NET and unmanaged functionality in a single runtime engine. The ease-of-use comes into play in several ways:

1. When you want to use .NET forms capabilities, you can. It is not mandatory.  Very rich applications can be designed using the core GUI capabilities within uniPaaS.
2.      Adding .NET managed code is simplified because your overall application leverages the benefits of the uniPaaS metadata-driven platform. Low-level programming is never required.     
3. uniPaaS’ tab and table driven interface allows you to avoid complex line-by-line scripting and coding. uniPaaS takes care of the typical programmer “housekeeping chores” so that there is less effort than normally expected to create a program.

Let’s review the seven main class categories in the Windows .NET form library:

Control, User Control and Form classes.  The Control class constitutes the majority of classes available in the System.Windows.Forms namespace. Controls are key to visibility. In other words, a control class is sued to provide the base functionality for all program controls that are displayed on a form in your application. You can think of a form as a window within your application such as a dialog box, modeless windows, Multiple Document Interface (MDI) client and parent windows.

Menu and Toolbar classes. The library also includes a category of classes for building custom toolbars and menus with your desired look and feel. ToolStrip is used for creating toolbars.  MenuStrip is used for creating menu bars.  ContextMenuStrip is used to create context menus. And StatusStrip can be used to create status bars.

Standard GUI Control classes. The Windows forms library included a number of mainstream controls for input (such as TextBox and ComboBox) display of data (such as Label and ListView) and firing of commands (such as Button).

Layout classes. The layout classes in Windows Forms help control the layout of controls on a display surface, such as a form or control. For example, the FlowLayoutPanel lays out all the controls it contains in a series, and the TableLayoutPanel provides a control for laying out data in a fixed grid. More sophisticated layouts can be managed through the SplitContainer class which is a control that divides your display area into adjustable parts.

Data and Data Binding classes.  You can also use Windows Forms to create the interfaces for binding to data sources such as databases, XML and flat files. The DataGridView is a sophisticated data control that allows for custom tables displaying information with specific  cell, row, column, and border properties. Also, the BindingNavigator and BindingSource controls allow you to develop interfaces  that navigate and work with data on a form in a standard way.

Helpful classes. It is possible to use a number of other helpful classes within the Windows Forms namespace that aid in the display of application related information in your application. Certain classes, provide Windows standard ways of displaying a ToolTip or an error (ErrorProvider).  And the Help and HelpProvider classes are useful for displaying relevant Help information to a user of your applications.

Traditional Dialog Boxes. The final category of Windows Forms classes that we’d like to discuss are common dialog boxes. Dialog boxes give your application a consistent look and feel for common and repetitive functionality such as opening or saving a file, manipulating text properties such as font, size or color, printing or any of a number of other common processes within your application. For example, the OpenFileDialog and SaveFileDialog classes display dialog boxes for opening and saving files by users. The FontDialog class provides a user dialog box set Font properties used in a particular aspect of your application. The PageSetupDialog, PrintPreviewDialog, and PrintDialog classes display well-known and easily understood functionality in a standardized way as well. In addition to the common dialog boxes, a MessageBox class is also available to create a simple box to display and retrieve data from the user.

Conclusion. In addition to all the standard classes within the System.Windows.Formsnamespace, there are of course a number of very interesting third party controls libraries that are worth exploring when you’re looking for that “something extra” or special pizzazz in your user interface. The trick is finding the right balance between uniPaaS, standard .NET and third-party controls within your application. That’s all for this trip to the library.  

The Benefits of Metadata Driven Development

Eyal Pfeifel, Magic Software’s Chief Technology Officer, recently sat down to discuss metadata driven development. In the video, he provides a useful definition of metadata driven development: “Metadata driven development means developers build business applications using metadata and not using code. Metadata is a high level definition of business objects like forms, dialogs, validations and other things that are part of a business process that build a business application.”

Eyal Pfeifel contrasts metadata driven development with traditional coding or manual programming. “Unlike code which is tied to a specific platform or operating system, metadata is a high level definition and theoretically can run on any platform or operating system. Given that you have the appropriate runtime engine, you can build an application built using metadata on any kind of a device, server or client,” says Pfeifel.  

As Chief Technology Officer for Magic Software, Pfeifel certainly knows what he is talking about when it comes to traditional programming languages. Magic Software uses these more difficult third-generation languages (3GL’s) to create the metadata driven platform that is integral to Magic Software’s higher level and more intuitive application platforms. For this reason, he is keen to recognize the benefits of the metadata paradigm over traditional programming. “One of the main benefits of working with a metadata driven development paradigm is that since metadata objects are high level business objects it is possible to build a complete business application in a much shorter time than it would take when using code.  And the same business logic that you can construct one time very easily is relevant for multiple platform and operating systems like desktops, servers and even mobile devices.”

As Magic Software introduces its impressively expanding capabilities as a mobile enterprise application platform provider, Pfeifel has found himself commenting a lot recently on one of his favorite subjects: mobile application development.  “Using a metadata driven platform it is very easy to extend an enterprise application that originally started on a desktop or on a server into mobile devices because once you have the runtime engine running on a mobile device, it can theoretically run any type of application that you built on a desktop,” Says Pfeifel.  “And you can extend your business processes into a mobile device without needing to rewrite the application from scratch and with minimal adjustments just to cater for the smaller screen size or different form factor of the mobile device.”

Magic Software has a strong reputation for providing expertise that can future-proof your application development investments. As one can see by sitting down with Eyal Pfeifel, Magic Software's future-proof expertise is based on extensive customer feedback, strong R&D investment and the mindset to continually think ahead. To learn more about the Magic application platform, visit magicsoftware.com.

Welcome to the Magic Application Platform Blog

Welcome to the New Magic Application Platform blog. 

Today, June 11, 2012, Magic launched a rebranding that reflects changes in the company and major developments in its product offering. Magic has experienced significant organic and inorganic growth in the size of its business. New customers and new business units are creating a new Magic that is becoming a formidable force in the IT industry. At the same time, Magic's core application and integration platforms are becoming smarter, more open and more future-proof than ever before. 

As trends like enterprise mobility, integrated IT services, Big Data and cloud computing become key to business strategy at all levels, the Magic application platform and the Magic integration platform have entered center stage as business solutions based on advanced technology. 

What was once called uniPaaS, is now the Magic xpa Application Platform. The emphasis is on the word "Magic." For years Magic's customers have referred to both the company and the application platform as "Magic." This makes sense. It fits the new identity of the company as it enters its fourth decade. The Magic of uniPaaS blog will remain available on the former site but all new Magic programming and IT articles will appear here. Followers of the Magic xpi Integration Platform can continue to find new articles and educational material on the Integrate My JDE blog which covers all aspects of the Magic integration platform.

It is refreshing to see Magic embrace a new identity that returns it to its roots. The company is offering this statement of its brand position: Magic accelerates business performance with smarter, future-proof technology and close customer collaboration. This echoes themes that you've seen in my blogs for several months now.  

As always, I welcome your input and comments on the Magic Application Platform.

Disclaimer: Magic (R) is a registered trademark of Magic Software Enterprises, Ltd. All references to Magic(R),  Magic(R) xpa Application Platform, Magic xpi Integration Platform, Magic University, and other marks both existing now and those that may exist in the future are hereby acknowledged and recognized by reference. All articles appearing on this site are the personal opinion of the author(s) and do not officially represent Magic Software Enterprises, Ltd. or any of its subsidiaries, affiliates or business partners.

The New Magic Software Application Platform and the .NET Framework: The Best of Both Worlds

The new Magic Software Application Platform, uniPaaS 2.0, implements a new .NET deployment engine, which turns any existing uniPaaS application into a native .NET application. According to Microsoft, the .NET framework is comprised of a Common Language Runtime (CLR) that provides an abstraction layer over the operating system; Base Class Libraries that deliver pre-built code for common low-level programming tasks; and development frameworks and technologies offering reusable, customizable solutions for larger programming tasks. The new uniPaaS 2.0 engine uses the Windows Forms .NET library as the GUI front-end for applications. To be clear, Windows Forms is the name given by Microsoft to the graphical application programming interface (API) included in the Microsoft .NET Framework. Windows Forms provide access to native Microsoft Windows interface elements by wrapping the existing Windows API in managed code. uniPaaS 2.0 seamlessly leverages this capability to provide superb RIA and client/server GUI capabilities. In fact, uniPaaS 2.0 provides full integration with the Microsoft .NET framework to significantly enhance application design, functionality, and overall user experience. uniPaaS 2.0 also offers new RIA-related enhancements.

With uniPaaS 2.0, Magic Software will soon be offering its first Mobile Enterprise Application Platform with support for devices running the BlackBerry OS or Windows Mobile 6.5 as a client deployment platform immediately and both iPhone and Android in the near future .

In a press release last month, Magic Software Enterprises (NASDAQ:MGIC) included a quote from a Microsoft product manager regarding use of Magic Software’s integration platform for SharePoint integration. With the release of uniPaaS 2.0, it becomes clear that Magic Software is now even more closely aligned to leverage underlying Microsoft Windows and .NET framework technologies.

In fact, one might even say that uniPaaS 2.0 is a .NET programming language (just as one might also say that it is an IBM i programming language or an AIX programming language or a Linux programming language). So the difference is that last week you could only really say of uniPaaS 1.9 client/server programming was that it was a Windows programming language. Now, one can see Magic’s application platform as fully supporting and being fully supported by the .NET framework. In this sense it can sit alongside Visual Basic.NET and other .NET programming languages for Windows servers and clients just as it can sit alongside RPG and COBOL for creating IBM i server applications, etc.

The good news for enterprise IT departments that have adopted .NET application development as an enterprise standard is that uniPaaS 2.0 now meets (and even exceeds) the requirements for being a .NET framework application platform. This is good news because unlike existing .NET languages, uniPaaS supercharges .NET in a way that no other approach can.

How does Magic Software’s uniPaaS 2.0 application platform turbocharge the development and deployment of business applications? First, uniPaaS accelerates the development on .NET framework application by providing straightforward and streamlined development methodology that further abstracts the development process without sacrificing control. Then, it stabilizes the performance and operational integrity of applications by leveraging our proven, highly scalable application platform technologies.

This release is just another example of Magic Software's long history of providing solutions that protect your applications from the underlying changes in operating system , client, server and other technologies. By future-proofing your business applications with the use of the Magic Software application platform, you are able to outperform your competition and surpass all expectations for your ability to adapt to whatever changes the future may bring. To learn more, please access these resources.

Take A Load Off: Use RESTful Web Services in uniPaaS

Take A Load Off: Use RESTful Web Services in uniPaaS

We’re pretty good at keeping "well-guarded" secrets at Magic Software. Sometimes we even release useful new features that few people know about. We made a lot of fanfare when we started supporting Web Services based on the SOAP protocol. In fact, I think I wrote the press release back in January 2002.

Here we are nearly 10 years later and uniPaaS now supports REST (Representational State Transfer) approaches to Web Services and few of us paid close attention when this feature emerged in the product with the release of uniPaaS 1.9e. But it is worth paying very close attention because RESTful Web Services can be accomplished without the complexity and overhead of SOAP Web Services.

REST isn’t something new at all. In fact, it is the way the Web has worked all along but with some rules added to help everyone get along.

What are RESTful web services?

Baiscally, a RESTful web service is a simple approach to web services implemented using HTTP and based on the architectural principles of REST. A RESTful Web Service has three resources defined:

• the URL address for the web service (you may call it a URI if you want, it is basically the same thing). The URL is the equivalent of a noun.
• the supported Internet media data type of the web service.
• the set of HTTP operations supported by the web service. Think of this as the verb.

The following table shows how the HTTP methods are typically used to implement a web service.

Unlike Web Services based on SOAP, there is no industry protocol for RESTful web services. In this sense, it is akin to a concept like Service Oriented Architecture (SOA) where a number of different approaches and protocols can be used to accomplish the objectives of the architecture. RESTful Web Services are based upon established W3C and OASIS protocols such as HTTP, URL, XML, etc. The REST architectural style is based on the idea that a client and server are interacting in a stateless manner with cached data via a uniform interface.HTTP 1.1 was designed to conform to REST. Unlike SOAP and XML-RPC, REST does not really require a new message format. Nevertheless, XML is the most popular type of REST message format. When you use XML, it becomes easier to represent the information resource in a variety of ways using XSLT and Cascading Style Sheets (CSS).

In uniPaaS 1.9e, we improved upon the ability of uniPaaS developers to employ RESTful Web Services by adding a new function: HTTPCall. This function may be used with a proxy server and supports SSL\TLS with the client certificate password protected and both basic and digest authentication schemas.

HTTPCall runs an HTTP request and returns the results. You can consume REST services by using HTTPCall with any and all verbs. This function can be used instead of the HTTPGet and HTTPPost functions, thereby simplifying implementation of RESTful Web Services in uniPaaS. The syntax within uniPaaS for the use of HTTPCall is as follows:
	HTTPCall (verb, service URL, message, [header1], [header2], …)
	The “verb” is a string indicating the method. The options include GET, POST, PUT, DELETE, and HEAD. You can GET a list or a specific member of a collection. POST is like an append operation in that it adds a member to a collection. PUT replaces an entire collection or a specified member of the collection. DELETE erases the entire collection or a specific member of the collection. HEAD is a header that provides additional header information. The “service URL” is the string that represents the HTTP address where you will retrieve the HTTP request. The HTTPCall function can easily pass a user name and password to the service URL for a secure, rights-based approach to Web Services. For example, when a uniPaaS client is accessing a web server that requires a user name and password, the URL should be HTTP://User:Password@[URL]. uniPaaS will also support secret names by following this approach: HTTP://%user_secretname%:%pass_secretname%@[URL] Obviously, the “message” is a string with the text of the message. There is no limitation on the message content. Messages are self-descriptive and stateless. The use of “headers” is strictly optional and you may include as many as needed. Each header may contain a string that provides additional header information as requested.
	As one might expect, the HTTPCall returns a BLOB containing whatever information results from the HTTP request. If the function fails to make the connection, a blank value is returned. You can get the response headers using the HTTPLastHeader function. Magic Software provides both Online and Rich Client sample programs that detail the use of the HTTPCall function. Look for sample programs EL23 and REL23 to get an idea of how this function can be implemented. One of the traditional disadvantages of REST is that it doesn’t do well with complex data architectures such as those of relational databases. In this regard, using uniPaaS allows you to bridge the gap between REST and traditional databases. With uniPaaS, information is exchanged and represented using RESTful Web Services while at the same time you can store enterprise data in industry standard databases. REST advocates will simply say databases are too complex and should change to conform to the way the Web works. With uniPaaS, you avoid that argument altogether. It just works.

Mobile Enterprise Application Platform: Any Time

Ten Key Questions to Help Compare MEAP Vendors

Comparing mobile enterprise application platforms (MEAPs) can be challenging. Quite often those that are seeking a MEAP solution do so precisely because they do not want to invest in developing in-house expertise in all of the programming languages and environments required to provide native client solutions for major mobile device environments such as BlackBerry, iPhone, Android and Windows. The IT departments ability to anticipate the challenges of each target device environment is often limited due to lack of familiarity with the differences in all these environments.

To complicate matters more, MEAP vendors are rarely what they appear to be. It is first of all necessary to try to separate out current capabilities from future plans in the vendor roadmap. One must then ask, what is the vendor history in living up to the promises in their roadmap?

Even once you have all this sorted out and have separated out marketing hype from actual platform capabilities, the task of making comparisons gets tricky. Is device management a necessary part of the evaluation, or should we consider that a separate category just as we consider development tools and IT operations software as separate systems in the data center? Evaluators need to carefully consider their own rollout plans versus the vendors plan for device support.

More important than any of these tangled issues, however, is the question of productivity. The reason for adopting a MEAP is to reduce effort. In order to live up to the need to develop and deploy mobile apps at anytime and anywhere, you need a MEAP that is truly metadata based, employs fully native clients, and has seamless capability to develop and maintain enterprise data center, enterprise cloud and enterprise mobile apps without duplicate programming efforts.

Here are a few key questions to ask a MEAP vendor?

1. Are native coding skills required to complete projects or make changes? Some MEAP vendors surprisingly do not complete the process of creating the mobile app for the target device. Manual programming and tweaking is required.

2. Will we need to use the native debugger to test our applications? If the MEAP forces you to debug their deployment capabilities on a target device, then you that means you are likely to be required to write code to fix any problems you find.

3. Can my MEAP platform also create desktop, client server and web applications? Some MEAPs are mobile only and have little or no capabilities for supporting other types of applications. This lack of support means duplicate coding for those environments.

4. Does the MEAP platform allow me to control the look and feel of the application so that I can develop with a native look and feel for each device? Will BlackBerry apps look like other BlackBerry apps? Will an iPhone app look and feel like an iPhone app? etc.

5. Does the MEAP platform vendor have a solid track record of back-end integration? Do they have a complete set of integration tools to allow you to integrate enterprise IT systems, data and processes with your MEAP platform? Integration to backend systems is a crucial component of providing B2E, B2B, and B2C applications. Without a straightforward solution for integration, you may end up spending months of unnecessary development time trying to integrate your mobile apps to existing enterprise systems.

6. Is the solution multilingual and can the vendor provide multilingual support? If you need a global solution, some vendors have limited reach in North America but not beyond.

7. How long have you been in business? Too many vendors are in startup mode with no guarantee that they will stick around.

8. Will you provide financial statements showing your revenues, profitability, cash on hand and debt position? If a vendor is unwilling to provide financial statements, then you are at significant risk that you may be dealing with a vendor that is on the brink of imminent financial failure.

9. Does the MEAP vendor have a parent company whose objectives are different from those of the independent software vendor that it acquired? If the parent company acquired the MEAP platform to serve the needs of its larger client base, will that be at cross-purposes to your needs?

10. Does the MEAP vendor have a coherent strategy for enterprise systems, mobile apps and the cloud? Can the vendor ensure that all of these solutions can be based on the same service-oriented architecture (SOA)? Is the platform capable of compositing existing application logic from Java, .NET, COBOL, RPG and other environments? A good MEAP platform will be capable of leveraging all that you have today and have a coherent strategy for deploying solutions in all of the environments that you need to be in tomorrow. A vendor that can future-proof your efforts will ultimately be the smart choice for development of mobile apps.

Once you have a satisfactory sense of what your vendor can offer, the question of how it is licensed and priced is appropriate. Some vendors adhere strictly to a per user pricing strategy. Others offer a per server pricing model. Some offer both or a hybrid. If you are developing a B2C enterprise mobile app, then per user charges are unappealing. But if you have a fairly small target B2E or B2B audience, then hefty per server pricing may be disadvantageous. In the final analysis, you will need a vendor that is willing to work with you to assure complete satisfaction and success. Evaluate vendor technical support, training and professional services. All these things combine to make the selection of a MEAP platform a difficult decision. But if you know the questions to ask, you are on the right track. To see a video announcing the Magic Software Mobile Enterprise Application Platform (MEAP), click here.