Credits: Jaxenter

Credits: Jaxenter

JAXenter: What are your duties and responsibilities within the Eclipse Foundation?

Christopher Guindon: I am the Lead Web Developer at the Eclipse Foundation. I often say to members of our community that our team is responsible for everything being served to your browser from Eclipse domains on port :80 and port :443. Obviously, this is not true but we do contribute to a large portion of it!

We build and maintain services and websites for the Eclipse community. We have an extensive list of web properties that we support. At the moment, I am really proud of the work that we are doing for the Eclipse Marketplace and our new API service.

The webdev team at the Eclipse Foundation currently includes Éric Poirier and myself. We work in the IT department led by Denis Roy. You probably know Denis as one of the Eclipse Webmasters and you might have met him at one of our EclipseCon events.

It’s a very exciting time to be a web developer! Tools and frameworks are evolving very quickly and it’s our responsibility to stay up-to-date to make sure that our websites are secure, fast, modern, and user-friendly.

 JAXenter: When did you join the Eclipse Foundation and why?

Christopher Guindon: I always had a passion for open source and I knew at an early age that I needed to work for a company that shared my same values and beliefs.

When I finished school, I started working for inter-vision.ca. At the time, it was a small startup that aimed to help not-for-profit organizations with open source. It was a great experience for me because I got to see first hand how a business could make money and benefit from open source. This was at a time where a lot of businesses, organizations, and governments were still hesitant to adopt open source software, mostly because they didn’t really understand it. As I became aware of all of this, I came across a job posting from the Eclipse Foundation for a web developer position. At that very moment, I knew that this was going to be my dream job. I could pursue my love for writing code and contribute to the awareness and the benefits of open source at the same time. This was a win/win opportunity for me.

It’s been five years since I started working for the Eclipse Foundation, and I still believe that this is my dream job. I love writing code, I love working with everyone at the Foundation, but most importantly, I love the Eclipse community.

JAXenter: Which project(s) do you like most? 

Christopher Guindon: I support and am passionate about all of the projects at the Eclipse Foundation but I do have a soft spot for the Eclipse Marketplace Client (MPC). MPC allows Eclipse users to discover and install Eclipse solutions directly into their Eclipse installation. The solutions shown in MPC are tailored to each user based on their operating system, Java version, and Eclipse release.

JAXenter: What does the future of Eclipse (and the Foundation) look like? 

Christopher Guindon: Back in the early days, we used to focus on Java tools, but the Eclipse Community has grown to encompass a lot more than Java alone. Now, we also have Eclipse Working Groups that are involved with geospatial, scientific research and Internet of Things (IoT) technologies, just to name a few. I hope that the community continues to expand and that the Eclipse Foundation remains the home of choice for innovative open source projects.

JAXenter: Finally — Eclipse Neon. What is your favorite feature?

Christopher Guindon: PHP development tool is one of the reasons why I use and love the Eclipse IDE so much. Our team writes PHP code on a daily basis, so it’s really great to see that it fully supports PHP 7 now.

I am very happy with the new features from JSDT (JavaScript Development Tools). They now support two package managers, Bower, and npm. They also included support for Grunt and gulp tasks. Tasks are now accessible from the project explorer view and can run via launch shortcuts.

I also love the Oomph project which allows users to manage personal preferences in their Eclipse workspace. Oomph is a very exciting project for us because it’s the first project to adopt the new Eclipse User Storage Service that our team built last year. The Eclipse User Storage Service (USS) allows Eclipse projects to store user-specific project information on the Eclipse Foundation servers. The goal is to make it easy for our projects to offer a better user experience by storing relevant information on our servers.

Credits: Theregister

Credits: Theregister

Online commerce giant Alibaba is among a crop of “new world” Java users seeking to shape the direction of both language and platform.

Alibaba, one the world’s largest users of Java, has entered the race for election to the ruling executive committee (EC) of the Java Community Process (JCP). Jack Ma’s ecommerce giant joined the JCP only three months ago – in August.

Also running for election to Java’s steering group are representatives of end user groups from China, Africa and Germany. One, the GreenTea Java User Group (JUG) in Shanghai, was founded and sponsored by technical staff from Alibaba.

Martijn Verburg, London JUG co-leader and jClarity chief executive, told The Reg that such diverse and new representation is a positive sign for a strong and growing Java. Also, it reflects a desire from the EC to attract more interest from outside the familiar pool of big US and European corporations.

“Java continues to show that it has broad appeal, attracting influencers that want to shape its future from a wide range of organisations,” said Verburg, who is also an EC candidate.

JCP chair Patrick Curran in May called the prospect of Alibaba’s membership “a very positive step, given its leading role in China, and indeed globally”. He believes that if Alibaba joins, other Chinese firms might follow suit.

It’s not just regional representation that Alibaba would bring; the commerce giant runs Java at massive scale and could have fresh input on web-scale Java. Alibaba reckons it has identified areas that could be redesigned to better serve its needs.

The firm claims in its election statement to have a world-beating Java footprint with “tens of thousands of machines running Java every second serving insurmountable numbers of web pages and transacting Alibaba’s full spectrum of services, including the world’s largest online ecommerce marketplace.”

Areas for change include that age-old hurdle to real-time performance – garbage collection, deployment plus just-in-time compilation.

“The environment we are facing is mostly a web server one, where short sessions come and go very quickly. We once again firmly believe that JVM/JDK/middleware may accommodate better by assuming certain behaviour and workload with web server characteristics. We therefore think joining the committee will help us express that,” Alibaba said.

Alibaba’s candidate is JVM team lead Haiping Zhao.

Should the big boys vying for a coveted seat be elected, power looks to be passing ever so lightly to the ever-important user groups.

Aside from Green Tea there is iJUG, an umbrella of 30 user groups in Germany, Austria and Switzerland founded in 2009. iJUG wants the JCP to be more open and democratic. This includes taking action on JSRs, should spec leads go missing.

That should be seen as response to the fact Oracle’s JSR leads stopped working on Java EE this year to concentrate on development of the vendor’s cloud instead – a fact that has seen Java EE 8 delayed and in the resulting frustration bred MicroProfile.io.

Also in the running are representatives of the Morocco JUG for the associate seat.

The JCP consists of 25 members but it’s the EC that guides development of Java. It approves and votes on all technology proposals, in addition to setting the JCP’s rules and representing the interests of the broader JCP community.

The EC consists of 16 ratified seats, six elected and two brand-new associate seats, with Oracle holding a permanent position. The EC ballot closes on 14 November with the results announced the next day.

Credits: Jaxenter

Credits: Jaxenter

In the 1990s when Java began to appear on the developer scene it met its competition from Microsoft head-on in that it struggled to gain an acceptable place within the international development community. However, over the years Java appears to have arrived at more stable set of infrastructure and development standards than Microsoft appears to offer now. This is the result of both communities taking maturation trajectories that were in a very real sense diametrically opposites of each other. Microsoft, at the time, was offering maturing technologies while Java was the “new kid on the block”. Both communities also offered completely different viewpoints towards their product developments. Microsoft offered products with “ease of use” as the underlying factor allowing developers to quickly create both desktop and web applications far more quickly than competing solutions. This was especially true when compared against the new Java tools. However, Java had its founding basis in the academic and scientific arenas.

One could see this easily with the many Java articles that took apart various interface controls that we in the Microsoft Community took for granted with the exception of third-party control developers.

The Java Community did have a difficult time to get its place as an accepted form of development until it presented an alternative to Microsoft products in the large enterprise development area, which was Microsoft’s weak spot since Microsoft products at the time were targeting division and department level applications. Once Java tools became more usable for developers, the large enterprise arena saw the advantages of Java development with its better-suited enterprise offerings (ie: J2EE, and later, the Spring Framework).

Today, we find a Java Community that appears to be far more stable than that of the Microsoft Community though one would not know it with the subdued reporting around it. Years ago such reporting was quite different as the two communities fought each other for developer supremacy Reading online magazines such as jaxEnter.com today, most of the articles appear to concentrate on existing technologies along with their refinements. The opposite appears to be true for Microsoft, which seemingly approaches product refinement the way the US Pentagon approaches new weapons procurement; both throw out perfectly fine technologies and start over with brand new and completely untested concepts.

In this author’s opinion, and as one who has worked with Microsoft technologies his entire career since leaving the mainframe world around 1989, Microsoft has made some serious mistakes with not only the products they are offering but how their style of developing applications has changed over the years. This appears to have happened most egregiously with the latest CEO of Microsoft, Satya Narayana Nadella, while under Steve Ballmer; Microsoft appeared to be more stable in this regard despite his terrible reputation.

With desktop applications Microsoft has now two types of development offerings, the original “Windows Forms” model and the more current and recommended “Windows Presentation Foundation (WPF)”, the latter being far more difficult in terms of styling and designing sophisticated interfaces. One of the overall concepts behind WPF was to make its development similar to web development and in that regard it has been quite successful. However, the complexities and the rather disjointed documentation have made this style of development difficult for many developers.

Web development is a somewhat different story with Microsoft, and for those who have read my pieces on it, you all know that my opinion on it is rather negative in that it is going in too many directions. Originally designed with the “Web Forms” model, which no doubt had its own set of drawbacks, this model had been exceptionally easy to create rather complex web applications despite the flaws inherent in its internal design. It still is.

Somewhere along the line…

Somewhere along the line some senior technical personnel got it in their heads that suddenly the entire Microsoft Community wanted what the Java Community had in this regard, the MVC pattern; also a possible result of the terrible infighting that has been reported regarding Microsoft product groups. As a software engineer using Microsoft’s products at the time I kept well abreast of the issues facing my developer community. Interestingly enough, I never found any such demand by its members. In fact, when ASP.NET MVC was first announced I instead found a rather substantial negative reaction to it.

Despite this I saw nothing wrong with such a product development. However, there was absolutely no need to turn the entire Community upside down to provide this new paradigm since those developers that did want to use it already had an Open Source alternative provided by the Castle Project’s, “Monorails”. This unique and capable offering provided MVC development for Microsoft’s web development exactly in the same fashion that Microsoft introduced its first version of ASP.NET MVC. In fact, if you did a comparison of the installations you would have found that the solutions created were exact replicas of each other, leading one to wonder if Microsoft’s first introduction of MVC was in fact a forked version of the Castle Project’s, “Monorails”.

Nonetheless, unlike the Java Community that maintained its initial toolsets and used them to successfully enter into the enterprise, Microsoft, though offering quite a range of quality tools did not provide a similar scale of constructs that could be used for all levels of development. It is true nonetheless, that with its introduction of the .NET development environments, which would become Java’s fiercest competitor, Microsoft did offer such distributed computing capabilities such as the Remoting Framework (and then later the “Windows Communication Foundation (WCF)”), which was supposed to be an answer to Java’s more mature J2EE implementation (Java would offer the alternative of the Spring Framework due to J2EE’s initial performance and configuration issues). Despite Remoting’s capabilities which were rather extensive at the time, the psychology of its usage did not reflect a similar strain of thought found in the Java Community. So while the Java Community’s enterprise level tools were all entwined with the ability to develop Java desktop and web applications, Microsoft’s offerings were rather too disparate to offer such a level of psychological cohesiveness.

This was an unfortunate failure on Microsoft’s part since .NET, even in its earliest configuration had a great deal to offer to both developers and organizations looking for modern rapid application development techniques, something the Java Community was not as equipped to offer. Nonetheless, .NET’s ease-of-use development features were as well designed as Java’s more extensive enterprise offerings. They not only offered developers a great way to create applications but also maintained a consistency for third-party companies who wanted to revise their tool offerings.

Over time the two communities began to mirror each other’s capabilities to a certain degree.

With “Windows Forms” and the newer “Windows Presentation Foundation”, Microsoft more than equaled itself with Java’s capacity for development of desktop applications through the use of Java, AWT and other tools. For web applications, Microsoft offered “Internet Information Server” as its standard application server while the Java Community relied on “Apache” and then later “GlassFish”, both excellent servers. For actual web development we had ASP.NET WebForms while Java had it’ “Java Servlets” and its MVC development paradigm; the former offering a one-to-one page process (web page to code-behind) while the latter offered a one-to-many page process (web page to multiple controllers). Over time both became accepted development methodologies for their developer communities. And though many in the Microsoft Community submitted complaints about certain difficulties with “WebForms”, no one to my knowledge was making any recommendations that it should be thrown out with the bath water. Unfortunately, Microsoft has developed a rather bad reputation for discontinuing very solid products. Though it has not announced any plans to discontinue “Web Forms” support, one can easily see that the emphasis is increasingly on the ASP.NET MVC platform. This is also true between the older “Windows Forms” platform and the newer “Windows Presentation Foundation”, though neither has been responsible for the amount of near hysteria that one can find over the use of ASP.NET MVC and its associated tools.

As an example of discontinuing fine products, Microsoft developed the desktop “SQL Server CE” desktop database engine. Coming in at around two megabytes for its footprint, it is a very easy to use engine for SQL Server developers and supported both 32bit and 64bit machines. As major SQL Server development continued, Microsoft decided to discontinue this highly versatile database engine in favor of “LocalDB”, which has around a 14 megabyte footprint on the desktop. Needless to say, this database engine is hardly on anyone’s radar as many have opted for the use of SQLite or Firebird.

With Microsoft continuing with its own refinements for the “Web Forms” and “Windows Presentation Foundation” environments, these models have come a long way and have matured into a very solid form of software development. They are both stable and offer a tremendous amount of flexibility for organizations that need to develop desktop and web applications quickly, efficiently, and with modern styled interfaces. At this juncture, Microsoft more or less offered as stable a platform as that of the Java Community. To be sure both communities offered different styles of development but both styles were mature and could produce whatever applications a business organization may require. And with Microsoft’s increasing focus on their “Data Center” servers, enterprise level development was finding a good home with Microsoft as well.

Nonetheless, with such success in both camps something went wrong on the Microsoft side of things. For the Java Community, which was quite open with their use of Open Source software, it was surprising that the basic tenets of software development never really detoured into the hype and clap-trap that has redefined the Microsoft development community. Much of this detour was a result of the ASP.NET MVC paradigm. And the reasons promoted within the Microsoft Community for MVC over “Web Forms” or WPF over “Windows Forms” are for the most part complete nonsense since all of these development models do exactly the same things; they either create web applications or desktop applications. One could argue that with emergence of mobile computing, ASP.NET MVC was a better solution but so far there has been no evidence of this in terms of Microsoft development.

The problem is that for Microsoft, which is much a marketing company as it is a software vendor, there has never been a recognition for the simple fact that development for business applications has matured to a point that there is little more that can be accomplished in this arena as it regards the development of new tools that will offer something substantially unique that it could actually promote a new form of development style. Unless there is some drastic change in the foundations that our hardware and equipment are created with such a radical change is just not going to happen.

Microsoft simply failed to understand that what they have developed is perfectly fine for developers, which reached an equivalent level of maturity as with the Java Community. And since Microsoft saw things through the lenses of a marketing organization (Why else would they make Steve Ballmer, a salesman, the CEO of the company when Bill Gates left?) they seemed to need the “next new thing” that would possibly get Java developers to convert to the Microsoft product line or encourage youngsters, teenagers, and college students to use their tools. Unfortunately, for all their efforts Microsoft appears to have failed in these veins since I have seen far more developers making comments about how they left the Microsoft Community than the other way around. And possibly this small exodus may have been a result of the growing ambiguity in development choices that Microsoft was offering. As to teaching youngsters to code; I have never heard of something so ridiculous. Like with any technical profession, there first has to be a certain level of talent for it to be of any use. Besides, Microsoft always has hidden agendas and in this case it is to develop a new level of cheap labor, not develop “critical thinking” skills.

All development paradigms are equal

All of the paradigms work efficiently and all have their advantages and disadvantages since in reality, there is no such thing as efficiency in development. For every technique implemented there is a disadvantage that has to be lived with. Thus, development decisions are based primarily on what a developer feels most comfortable with as well as what they know. Despite the technical attributes and the science behind them, for the most part such decisions are quite subjective in nature. And considering that most technical managers could care less with the exception that their technical choices will not get them fired, I doubt that there is any serious concern on their part as to the merits of any particular technique for development.

I enjoy working in VB.NET; so shoot me!  I can work in C# just as efficiently and do but I came up from the DBase world in the late 1980s and feel most comfortable with 4th generation like syntax. We did some great things back then with the DBase environments and it’s somewhat of a shame that they were relegated to the dustbins of history.

Today, in the Microsoft Community, we find that we are experiencing with their tools what the Java Community experienced when it first made its emergence in the industry; concentration is on tools, techniques, and gimmicks, instead of quality application development without regard for the tools used.

Nonetheless, mature solid software development tools are not easily disposed of. A good example of this is the longevity of the main 3rd generation languages of Visual Basic, C#, Java, and C++. All of them do everything a developer requires for his or her work and have done so for quite some time; everything else, for all intents and purposes, is mere distraction and fluff. It is true that there are certain languages that have been developed for specific purposes such as Modula III, Prolog, and some more of the recent dynamic languages but for the most part the primary development languages have remained the forces in software engineering for many years once the mainframe saw its demise and will probably remain so for a long time to come.

Microsoft application development — The original and mature style of development

Once Microsoft released “Windows Presentation Foundation” in 2008 it had come to the point where it could promote a single style development for both desktop and web applications. Had they promoted such a unified environment, while refining it to support the emerging mobile environments, our side of the fence would have been far more stable in terms of development issues since our knowledge bases would have had far more depth.

As it regards these environments there are many “technical” advantages for using MVC (web), MVVM (desktop), and the like but in the end none of these advantages provide much in the way of benefit to the majority of organizations who require application development.

For example, many developers support the idea that using such paradigms can make testing far more efficient since developers can use a variety of testing frameworks and test the components separately from each other.

However, there is no evidence in the difference in subsequent quality by using good traditional testing techniques and using the more current ones. In combat fighter aviation there is one axiom that all fighter pilots have learned since the advent of fighter aircraft; it is the pilot behind the stick and not the airplane that makes an engagement a success.

In both styles of testing one has to take time to test properly. Traditional testing may be more of a manual effort but the extra time taken in newer forms of testing (“Test Driven Development (TDD)) will be applied to the additional development of testing code. And bad testing can occur in both testing models.

In fact, with traditional testing it is less acceptable to allow defects into production environments since that is the intent of such Quality Control. However, I cannot count the number of articles I have read where it is now quite common to discuss the allowance of defects into production processes with TDD/Agile since the justification is that it will be found quickly and can be easily rectified through automated deployment processes. Tell that to an end user of such application when something goes annoyingly wrong.

The style of developing applications with Microsoft tools without the MVC and MVVM paradigms is still based upon the single middle-tier module that captures and responds to user requests. In standard “Web Forms” (ASP.NET) this module came to be known as the “Code Behind” and is more or less called the same with the newer “Windows Presentation Foundation” (WPF) desktop applications. Surprisingly, Microsoft didn’t seem to come up with an acronym for this module in this environment but it is more or less the same thing. Thus, in both cases we can look at this type of development from the standpoint shown in the graphic below.

Common Sense Software Engineering

This graphic demonstrates how it has been accomplished historically on most development platforms but Microsoft more or less codified it in their products. There is absolutely nothing wrong with this model on the web as long as you are not continuously passing massive amounts of data back and forth; if so, performance will noticeably suffer.

The attempt to make the web more performance efficient has found developers as well as vendors coming up with techniques to avoid a complete “post-back” of such requests by a user. The result was the introduction of AJAX, which even today is the basis for all such calls to the backend that doesn’t involve a complete submission of the web form. Microsoft AJAX, despite some of its drawbacks, actually works quite nicely and is still being maintained professionally. You simply cannot beat the ease-of-use that the AJAX “UpdatePanel” affords developers.

For desktop applications, this is not as much of concern as the middle-tier module (response\request) for WPF or “Windows Forms” resides on the same machine as the interface and the user working with it.

Nonetheless, for the web, developers kept on pursuing some type of “silver bullet” that would somehow yield maximum performance in their applications. The result was that the pursuit of new tools and frameworks became a guidepost for Microsoft developers in terms of their skills and capabilities. Microsoft foolishly followed suit instead of concentrating on the refinement of their core products. The Java Community, apparently rather satisfied with what they have accomplished has found little need to rush into unknowns like the Microsoft world.

The reality is that on the web, as system engineers wrote years ago, performance is a matter of hardware and configuration and not so much code, though you can do things to make the responsiveness of an application better. In addition, in large scale applications such as are found on the web or very large client-server applications on the desktop, the pursuit of performance is largely an illusion since the overriding concern in both types of applications is “concurrency”, which will exclude the ability to develop maximum performance. What you want is acceptable performance when large numbers of users are accessing the application.

True N-Tiered development

In terms of development, many Microsoft developers continue to make a mess of how they handle the “code behind” modules by loading them down with just about all the necessary processing required for each interface form. The same has been done with “Windows Forms” and WPF development. And undoubtedly this happens just as often with Microsoft’s version of MVC. This type of development causes inherent bottlenecks to the applications since such modules were actually to be used as “dispatchers” to other modules that would handle the actual business logic and backend processes. Thus, the actual construct of this style of development would look as follows…

1

The process modules in this case then represent what we used to call the middle-tier while the interface and request\response (code-behind) modules represent the frontend tier, with the request\response modules being implemented on an application server in the case of web applications or the same machine in terms of desktop applications.

The process modules were also known as business objects where the data being passed back and forth to the clients would be manipulated through calculations, text transformations, among other types of algorithms. Specific modules that could be shared across the breadth of the process modules were designed to implement specific but more or less generic forms of processing such as database access, security authentication, and common string manipulation functions to name a few…

2

Finally we have the backend tier, which is comprised of the database.

3

To many older developers this should be common knowledge while for younger Microsoft professionals this should have been the proper way they were taught to develop high performance applications. Like a “Porsche”, “There is no substitute!”, no matter how you slice or dice it.

True N-Tiered development; The infrastructure is more important than coding

However, even if this coding infrastructure is set up efficiently and cleanly, a heavily accessed site will most likely not yield the performance gains one was hoping for. Even if the application is developed with ASP.NET MVC instead of “Web Forms”, the many controller calls from the router may provide a severe bottleneck given that the routing has been the historical point of contention with MVC since this aspect of the MVC framework has been historically based upon “Reflection”, which is not the speediest process on the planet.

Since I am not a Java developer I do not know how this community circumvents these problems. However, being a community that grew out of a more sophisticated background than we Microsoft developers I would guess that the next recourse is fairly common with large Java applications. However, the Java Community did incorporate servlets that were in a way, mini-services that would process requests and responses on the middle-tier. It was quite ingenious and still works quite nicely.

Back in the 1990s before the rise of popularized manifestos, MVC, JavaScript, and the like, the idea of actual distributed computing was a foundation for true performance in either web or client-server applications. In fact, one of the best developer manuals on this subject was actually written by a chemist turned programmer who developed high-performance web and client-server systems for the State of North Dakota (It may have been South Dakota, I don’t remember.) that had over 1500 clients hitting the central systems at any one time.

This scientist worked out the framework for a hardware\database configuration that even today simply cannot be beat for large scale applications. He took the standards of the day and designed the framework in its entirety, measuring performance benchmarks for each level of the configuration until he had refined each of the levels to an optimal efficiency.

However, with the rise of ever faster micro-processors these foundations were quickly overshadowed due to budgets that would also become defined by the rising outsourcing mania.

And yet, it was these foundations that provided the concepts of distributed computing other than the fact that such systems supported many remote clients.

To return to the above graphic, each of the various levels of processing to process optimally could not rely on a single machine to do so. However, that is what many IT organizations do today. Nonetheless, larger organizations do provide very powerful application servers, which encourage the use of single machine deployments.

Though such deployments may yield satisfactory results, unless the server is very powerful, such as with a mainframe or a set of high-powered UNIX machines, the scalability of such configurations will be finite.

To work with this, developers have turned to focusing on their code as the area where performance bottlenecks can occur. In some cases, increased performance can be accomplished by making coding refinements, but in reality, not all that much. This is because true performance is based upon hardware and not software. Thus, no matter how efficient one makes their code it will only run as fast as the machine it is deployed on can process it. The more clients a machine has, the slower the performance will be as the single machine will have to work increasingly harder to process the work load.

To work with such a limitation, developers began implementing threading operations in some of their applications, which again is mostly based upon the hardware available. An early document suggested a maximum of ten threads per microprocessor with an optimal recommendation of a single thread per micro-processor. With machines that could incorporate multiple microprocessors this seemed like a substantive idea. However, how many organizations provide 32\64 core machines for their applications and how many of those machines are set aside for a single application? I would suggest not many.

The result was that threading found its niche by providing flexibility to the interface, which is what one of its intended purposes always was. And threading does work very well when implemented properly, you just have to be judicious about it.

Within this type of implementation we also have found the rise of asynchronous programming. However, this type of processing only shines when an application has a long running task that can be placed on a background thread since the data is not needed immediately. This style of programming is not really about performance but again about flexibility.

Again getting back to the previous graphic, what we need to get maximum performance out of an application that can be easily scaled is also something that very few organizations will opt for since it takes time to design, test, and has its own expenses to implement. Nonetheless, to do this we start with a basic hardware configuration as shown below…

4

Before we move on, please take note of the database section in the above graphic. You will see two types of database engines, OLTP for transactional processing and OLAP for query processing. Why do we need two different types of database engines for a single application? For rather small applications we don’t but for applications that need to scale now and possibly in the future this is the standard for setting up the backend tier. OLTP databases are most efficient when used for transactional processing while OLAP databases are optimized for querying. Though OLAP database engines are touted for Business Intelligence systems, the reality of these systems is that such systems are optimized mostly for querying in addition to their numerical functionality.

To ensure that each database system is kept up to date in terms of its data, the OLTP database engine is designed to carry any updates over to its OLAP sibling.

By splitting out database systems in such a manner you can actually increase the performance of the backend by over 50% by allowing each database engine to do what it does best.

Finally, which demonstrates the increased cost of such an implementation, each tier is composed of multiple machines and the number of machines increases as we get closer to the frontend tier (interface). The scientist who worked out the performance benchmarks for each tier in his own designs found that as a process goes further down into the tiers of this infrastructure, the less amount of time it takes for the lower tiers to process. This is because each tier of machines has to actually do less in terms of responding to a user request. As a result, this type of infrastructure would look like the updated graphic below…

5

This latest graphic then demonstrates the proper configuration for a large scale deployment of a high concurrency application.

Each level of this infrastructure can be linearly scaled out by adding additional hardware components as each level would be made up of machine clusters.

The response to this type of infrastructure by many would be that it is too costly and time consuming to design and implement. And they would be correct. However, this is the proper technique for implementing high-performance systems and there is very little that can enable one to get around this.

The hype today, especially in the Microsoft Community, is that we can build such high performing applications with the use of scripting languages as well as the use of the MVC paradigm with C# or VB.NET. This is simply not true that this is all that is required but it makes for good marketing. Good application development not only requires clean and efficient code but an infrastructure that can provide the power that the code can take advantage of.

Performance-based code is highly overrated

No doubt the majority of Microsoft organizations do not follow the aforementioned standard due to the usual reasons; too much money, too much time needed for the design, both of which I mentioned previously. Companies like to work on the cheap and so the network and hardware people think of ways to combine applications on to existing hardware, which as soon as is done cuts the performance of the heavily used applications significantly. Such combining of applications is fine for low or even some medium use applications but overall, where performance is concerned, such combinations will only hamper the response times.

The last excuse organization people love to use is the “perfect world syndrome”. “Well, in a perfect world we would have this.”. The problem is that no one even tries to get near anything resembling credible infrastructures except for the technically savvy organizations.

The result of this derailing of actual n-tiered development has fostered the idea that applications can be made to perform very efficiently through refinement of code. For the most part this is utter nonsense but in the attempt to produce such performance technical managers have put terrible pressures on their developers to refine their code bases to the nth degree saving only milliseconds in time. This is not to say that you cannot find substantive performance enhancements in refining existing processes but it cannot be done simply through a refinement of existing code bases.

Years ago I worked with someone who thought he was the “gift to object oriented programming” and only he knew how to develop code properly. I am quite sure that everyone reading this piece has experienced a person of this nature at one point (or many) during their careers. There are plenty of these “fools” out there.

This fellow in particular just about cursed me out for a set of database queries I had written and placed as singular selects in a store procedure. This fellow promptly redid my stored procedure combining my queries into a joined set of queries. I accepted his work calmly and out of curiosity proceeded to run the performance benchmarks on the original stored procedure and the updated one that this fellow claimed was the proper way to write what I was doing. I never told him the results thinking he would just waste my time even more by trying to refine his own work. Nonetheless, his work took 35 milliseconds longer than my original code.

In either case, my faster stored procedure or his slightly slower one in the scheme of things would make little difference since Humans cannot interpret time at such levels. Yet, such attention to the coding of developers over the years has become near sacrosanct in many organizations to the detriment of all and everything else involved since for the most part it is a giant waste of time; especially if the infrastructure on which the application will run is not optimized properly. Any student of modern compiler theory and internals will be able to tell you this.

First and foremost, all of the compilers in today’s business world whether they be for the source-code languages or the database systems are extremely well optimized. Even if your code is somewhat inefficient, these compilers will make up for it by providing the best optimal solution for what you are attempting to write. Does this mean you get to write sloppy code? No…

What it means is that the attention to such performance details in your coding is more esoteric in the endeavor than in actually yielding increased performance results. It means that good clean code will work well and will most likely still be optimized by the compiler. Bad code, will work… well badly but probably not as badly as one would expect since the compiler will most likely eliminate some of the issues.

Note that we are talking about working code in both situations here not code that simply is so poorly written it will not work or barely do so.

To the last, I did work on an application that had been completely coded by someone else. The coding was atrocious and many of it completely wasteful. In fact, after having been able to study and work with the application for some time I found that at a minimum at least 50% of the code was unnecessary and could be removed if the application were to be re-written. Though I never had the opportunity to do this, the application, for all its inherently poor design and coding, actually operated reasonably well in terms of user response and processing. And this included a very poorly designed database as well.

No matter what type of application you may design and implement as long as you write your code in a clean and legible manner it will work just fine under low loads of activity. If you refine your code as much as possible towards making it as high performing as possible it will still work to the same degree under low levels of load activity since the optimizations that both you and the compiler make to your work will not be able to be interpreted by Human users. If you apply the implementation to a situation where there is to be expected a high concurrency rate, no matter how well your code is written it will fail to perform properly without the proper infrastructure. It is that simple.

Microsoft developers can do better than JavaScript and all its related tools

Despite these fairly simple engineering axioms, developers have still tried to optimize their applications in various ways that attempt to work around poor infrastructure implementations.

Today, the apparent standard on the web in the Microsoft world is what we used to call the “fat client” where as much as possible is placed within the client area of an application. The thinking is now that JavaScript reigns supreme and that as long as one implements all of the necessary libraries and dependencies on a web page everything will be highly efficient.

It is rather surprising to see developers praise a language that was never designed to do what it is being used for now while at the same time increasingly develop ever more tools that make use of the same language in a way that appears to make the whole sloppy mess in some way extremely recursive from a figurative sense.

JavaScript, like all languages of its type, falls within the domain of what we now call “dynamic” languages, which means that they are completely interpretive. In turn, this means that they are in general, inefficient no matter how fast the JIT compiler may be. Their primary advantage was for quick development times and not quick performance.

The use of such a technique encourages the building of applications that use individual data calls to the server, which will respond in kind. Some of this design came out of the mad rush to eliminate as many calls to the server as possible via post-backs, which entailed the passing of undesired amounts of data.

To some degree this concept made sense. However, it appears to have been lost on Microsoft developers especially that this form of data call was rectified rather early on with “Web Forms” through the use of the “web method”, which works quite nicely. It uses the same type of call within the popular “jQuery” framework (as well as others) that one would use if the call was made to a controller in an MVC application.

So does it matter where the method may be implemented; within a single-page code-behind or an MVC controller, which may be only one of several that will receive requests from a single web page? Most likely not…

It is true that sophisticated developers have made legitimate complaints about the way that Microsoft’s ASP.NET “Web Forms” does its processing against a “one to one” web page and its corresponding code-behind module. However, many of these complaints have been addressed over the years through refinements that Microsoft has made to the “Web Forms” paradigm. And the same has been true of Microsoft’s ASP.NET MVC implementation or there wouldn’t have been so many version releases in the past 6 years. The issue is why did we ever need two divergent development paradigms for the web when the original and more mature model offers nearly identical performance power while being far more flexible to develop with?

The Microsoft community has become erratic when compared to the Java world

While the move from “Windows Forms” to the “Windows Presentation Foundation (WPF)” has made a lot of sense in the way that now both web and desktop applications can now be developed in similar styles, the move from ASP.NET “Web Forms” to ASP.NET MVC has not had a similar level of credibility despite what the pundits may say. In fact, it is this move that has had a terrible effect on Microsoft development stunting the growth of more mature technologies that worked equally as well.

In some respects some of the thinking behind these evolutions has resulted from attempts to break out the tasks involved in application development to separate groups so that one group could design the interface while another would implement and test it. This makes sense but in most real world situations does not often happen in the Microsoft Development Community. Instead, developers tend to be responsible for most aspects of application development. This is why in job postings for Microsoft developers you often see a laundry list of skills requirements for the candidates; a list so long that no one could possibly be well skilled in all of the items. If the Java Community has found the same style of job offerings than it is familiar with this problem.

Nonetheless, one of the results of these changes in the Microsoft development environments has been to take advantage of the now many free software offerings from the Open Source Community to create new tools based upon inefficient language mechanisms not necessarily out of necessity but instead from wanting to try something new. There is nothing wrong with this endeavor but when a company attempts to mold all such activities into an existing development environment such as Visual Studio you land up with 6 gigabyte installations, most of which each developer will hardly use, taking advantage of only that which interests him or her.

Microsoft marketing consistently touts the advantages to creating great applications and modern user experiences with such new and “exciting” tools. However, if you have been in the industry as long as I have, you find that the marketing has become highly redundant by repeating the same mantras that began with the release of Windows 95. Nothing ever really changes…

Don’t get me wrong, Microsoft has some great development environments and tools as does the Java Community. However, there is a limit to what can be effectively done with the development of business applications using current protocols and infrastructures in either case. The Java Community has refined its offerings around scalability from the beginning and has matured in that endeavor. Microsoft on the other hand got off to a good start with its own offerings and could have done much more with these initial environments if they had stuck to refining what were already decent foundations.

However, instead of doing this Microsoft will persist to ensure new offerings in some misguided attempt to remain relevant while making these offerings as bloated as the original ones were claimed to be seeking that multi-pronged “silver bullet” that will not only yield high performing applications but offer efficient development environments that will convince many in the Java Community to convert.

I believe this is a fool’s errand but businesses are often run by people who are perceived to be intelligent but really aren’t. Good developers understand what they need to create good applications and it would behoove Microsoft to stop throwing everything out with the bath water and start again filtering for the community what is necessary, makes sense, and defines what makes for good ease-of-use development environments. This would be a far superior approach than turning their entire section of the industry into a technical nightmare creating a future that is based upon quicksand…

Credits: Gsmarena

Credits: Gsmarena

Google promised that the newest developer preview would be available to flash starting this month and Google was sure able to deliver on that promise. And with great timing as well, tomorrow is when the Google Pixel and Pixel XL are officially going on sale in Verizon and Best Buy Stores in the US with Android 7.1 out of the box.

It looks like Google is taking a more hands-on approach with the way it handles updates for its Nexus devices. We’ve never had developer previews this early on, and for an incremental update, nonetheless. It looks like Google is really committed to delivering the quickest updates to its Pixel devices, and the best way to do that, is by ironing out the kinks with the older Nexus crowd.

The Developer Preview is available to flash for the Nexus 6P, Nexus 5X, and the Pixel C.

To install the developer preview, you can do either of three things:

  • You can sign up for the Android Beta program and you’ll be able to download the developer preview OTA.
  • You can download the entire factory image as a TGZ file and flash the image to a phone by using the flast.bat method.
  • You can download the OTA zip file which will bring your device to the latest preview build.

If you have no idea what any of the above methods mean, we suggest that you stick to the first method: enrolling for the Android Beta program and accepting the update over the air. Just remember, if you want to revert to the most recent public software, your data might be wiped in the process.

Credits: Clapway

Credits: Clapway

PHP Developers are great people. They have an open-minded attitude and great conferences for networking. That being said, minorities are underrepresented in the community. So to help shed light on this issue one man went to Kickstarter for a unique idea that will surely make GitHub fans happy. Here are 5 things to know about it.

1. THE PHP ELEPHANT HELPS TO SPREAD AWARENESS AMONG GITHUB FANS

This rainbow-colored elephant is not just fluffy and cute, but it’s a symbol. A symbol to reflect diversity among the community. Hopefully, it will serve as a reminder not to discriminate based on the race, gender, sexual orientation or anything else in the realm of technology. Furthermore, it’s cuddly. You can’t really argue with that.

2. PHP ELEPHANTS ARE COLLECTABLE IN GITHUB COMMUNITY

Over the last few years, these “Elephants” have become a collectible item. Usually, they’re used to promote conferences, frameworks and even help fund campaigns on Kickstarter. Hence it was just a natural migration to the rainbow elephant to represent diversity. Will they become the next Beanie Babies? That’s up to you.

3. GITHUB FANS CAN SPREAD DIVERSITY WITH PHP ELEPHANT

So how do you promote diversity with this rainbow elephant? After all, money raised on Kickstarter can not be donated to a charitable cause. The secret is the presence of the Elephant. Just having it around the house or office reminds everyone of the diversity issues that exist out there.

4. GITHUB FANS CAN CONQUER THE WORLD WITH PHP ELEPHANT

If people can dress up as clowns and make a difference, then spreading rainbow elephants everywhere across the world can do the same. The only difference being this is actually for a good cause. Hence, stock up on these colorful animals and get to work. Only you have the power to spread diversity across the globe.

5. PHP ELEPHANTS NEED YOUR HELP, GITHUB FANS

According to the Kickstarter campaign, 1,200 small “Elephants” need to be ordered to meet the minimum order requirements of the factory. It seems like a big number but, considering the size of the developer community, this shouldn’t be a big deal. You hear the cry for help. Hence, it’s your duty to answer it.

 

Credits: Nordic.businessinsider

Credits: Nordic.businessinsider

Business Insider is the most popular business news site in America. We also run several other popular sites such as Tech Insider; as well as BI Intelligence, a premium subscription service for industry professionals. With a global family of sites across Europe and Asia, we are quickly closing in on a billion page views per month.About the Job:

The role is located in New York City’s Flatiron district. As a backend engineer at Business Insider, your code will reach 100 million readers around the world every month. We face exciting challenges every day due to the demands of our growing audience and the 24/7 news cycle. You’ll report directly to managers who understand technology and even write code. The backend team has many opportunities for a motivated engineer to have a huge impact, and be recognized for it.

About the Engineering Group:

    We do the majority of our server-side development in PHP with MongoDB, Memcached, Symfony, Solr/Lucene, Doctrine, and more. We believe in using the right tool for the job, so we also have a few services written in NodeJS and Python, and a growing number of projects being developed in Go. We use Docker in development and production environments. We are always exploring new tools and ideas as our needs evolve, and we love working alongside people who are willing to try new things. We do daily deployments across many projects. We have dedicated QA and DevOps teams. We do code reviews, write unit tests, and believe in the value of coding standards. We recognize achievement, and promote from within. We encourage collaboration, knowledge sharing, camaraderie and fun. We offer competitive salaries and great benefits.

Requirements:

    Experience with PHP 5 in production applications Proficiency with UNIX commands Experience working with at least one relational or NoSQL database Experience using version control software, preferably Git A solid understanding of OO and MVC design principles, RESTful APIs, caching concepts, the HTTP protocol and general web architecture You write clear and concise code that teammates want to read and build upon Ability to write code that performs at scale You are self starter who takes ownership of your work You are willing to contribute meaningfully when the team is solving hard problems You have genuine enthusiasm and love of programming

Bonus/Nice to Haves:

    Experience with Message Queuing services (SQS, RabbitMQ, IronMQ etc) Contributions to open source projects or personal projects Big Data or Analytics experience Experience with AWS or other Cloud providers Experience with subscription platforms and/or payment processors Any experience with major JS frameworks such as Angular, React etc Experience leading small teams of developers

 

Credits: Openpr

Credits: Openpr

For a lot decades now, the demand and increase in developing a website has been on the increase. Out of a lot of server side scripting languages, PHP over the years has been an outstanding language to use. PHP as an acronym stands for Hypertext Pre Processor.

The first and foremost advantage of using PHP language is the fact that PHP is an open source server side programming language and is certainly free. Although, it is possible to hire a professional PHP web developer in order to customize your web site as per your company demands, which is really economical. Dependability and better functionality makes PHP the choice of PHP programmers with Clinical SAS Programmer.

Second is the rich flexibility this strong language provides. Nowadays, dynamic websites are in great and increasing demand because of their special characteristics and user friendly features, using PHP programming language while developing a dynamic website gives it better usability and more security. The classes provide by the PHP library makes it flexible in developing a dynamic user friendly websites.

Third is the upper hand that PHP supplies while running multimedia technology. PHP is not dependent on the external plugins to run the applications; the servers execute it and thus needs nothing instead. Also, the recent development over time shows that PHP as a programming language has developed enough to meet various requirements of the clients which were impossible to meet in previous time.

Object Oriented Programming Feature. The object oriented programming feature makes it possible for robust application to be developed. The use of object, classes and methods enables a PHP programmer to develop programs that are easy to run and compile. With the object oriented programming feature, a programmer can modify a code easily to suit a particular purpose.

The above benefits that were mentioned in addition to various other have made PHP popular and most valuable language for developing dynamic sites.

Credits: Techspective

Credits: Techspective

Prevention is better than cure. It’s a saying that’s made us all think about the impact of our current decisions on our future selves. So, we do a little more exercise, eat a little less and try to make small alterations to build a brighter future. It’s the same ethos for those organizations that fail to take software security seriously. Small changes in the short term will save you from catastrophic events in the long term that can easily damage your reputational integrity and put your business at risk of massive financial loss due to regulatory fines, or outright theft.

An sSDLC (secure Software Development Life Cycle) is, therefore, a vital component for your organization’s future health. Like a personal trainer running through your code, it monitors your software to ensure it will run as safely and efficiently as possible without falling into any security potholes such as the high-profile hacking attacks and data breaches that regularly hit the headlines.

In other words, while it’s common practice for many frameworks to perform security-related activities only as part of the testing phases towards the end of the development lifecycle or current sprint, an sSDLC integrates security activities across the lifecycle to help discover and reduce vulnerabilities early on.

The result? Your software is of the highest quality. It looks its best and is fighting fit. Your organization makes security a continuous concern across the development cycle to produce more secure software. Any flaws in the system are detected at an early stage, resulting in cost reductions thanks to swift detection and resolution of issues. Stakeholders are more aware of security considerations and your organization sees an overall reduction of intrinsic business risks.

How does it work?

Whether your current framework uses waterfall, iterative or agile methodologies does not matter. Generally speaking, an sSDLC is set up by adding security-related activities to your existing development process. Such activities include the implementation of scanning tools to ensure your software adheres to the rules of your sSDLC. According to application security solution provider Checkmarx, while it’s important to tailor your sSDLC to your organization, there are four basic steps to facilitate secure software development and to get your sSDLC scans up and running:

1. Build an easy-to-understand and transparent process

You must engage with your development teams at an early stage of the sSDLC deployment process so they understand exactly what to do when conducting a scan. For example, when and what should they scan within their code? And what are next steps if the scan results reveal vulnerabilities? Clear online documentation is a must. You should provide a collaborative platform where developers can communicate with your security teams to share and access information, ask questions and search for advice during these early days, and into the future.

2. Gradually deploy scans to the UIs

Don’t migrate every developer over to your sSDLC scanning system in one go. Gradually implement scan capabilities to a handful of teams, taking your time to ensure each individual team is comfortable with the new scanning systems before moving onto the next team’s implementation. This will help your organization to understand the impact of your sSDLC scanning system on processes, people and the current development landscape, allowing you to correct any teething problems before it’s launched across the entire business.

3. Educate your developers

Train your developers to ensure they understand any vulnerabilities exposed by a scan and how to deal with them. Make sure they understand the associated tools and how to interpret the scan results. For example, if a scan detects a major issues, your developers must understand that the build needs to stop to prevent vulnerable software entering the production environment. This training could be done with a series of workshops, online courses, one-on-one training or a combination of these methods.

4. Handpick some training advocates

Train a squad of trainers so that every development team has at least one member with the knowledge and experience to train other users. These sSDLC advocates can then support their individual teams, as well as run scans and review the results.

These four steps will set your organization off on the right foot for a healthy future with an sSDLC. As with any new regime, it takes time to change bad habits for good habits, but a transparent and iterative approach, backed with a healthy dose of training, will ensure the future wellbeing of your organization.

Credits: Dzone

Credits: Dzone

 

It is the responsibility of data professionals to protect business data. Changes to the structure and coding of software that is essential to organizational operations must be executed with little downtime or data loss. Consequently, database administrators work tirelessly to prevent system crashes and data failures. However, the risk of failure in deployment, while possibly minimized, can still exist.

Release management tends to anticipate positive results. However, real world technology at times brings about undesirable results when the release doesn’t go precisely as anticipated or planned. When you have tested software changes to the database before confirming changes into the system, and you have test automation integration, QA has performed analytics with refined testing metrics, and scripts have been tested in staging against a copy of the database, red error messages still may cascade down your testing screen, indicating a crash and burn of your hard work and concentrated efforts. What do you do now?

What are the options for getting back on track when operations respond to software releases with system crashes? Do you use a backup to restore system functions? Do you idealize the system with abstractions then switch back to the real-world issue? Do you execute a software rollback to revert the deficiencies while preserving the database?

One way to carry on with software functionalities is to fix or patch specific software issues and execute another release. However, fixing the software only addresses the application deficiencies. Software fixes do not approach the possibilities of system or interface errors.

Therefore, when things go awry, software rollbacks are the all-inclusive manner of return to a point before the act-up occurred. Rollbacks return the software database to a previous operational state.

To maintain database integrity, rollbacks are performed when system operations become erroneous. In worst case scenarios, rollback strategies are used for recovery when the structure crashes. A clean copy of the database is reinstated to a state of consistency and operational stability.

The transaction log, or history of computer actions, is one way to utilize the rollback feature. Another is to rollback through multi-version currency control, an instantaneous method of concurrently restoring all databases.

At times rollbacks are cascading, meaning a failed transaction causes many to fail. All transactions which the failed transaction supports must also be rollbacked. Practical database recovery strategies avert cascading rollbacks. Enterprise, development, and QA departments therefore consistently seek to devise the best strategies for software rollbacks.

Best practice strategies are to avert the need for software rollbacks through incremental and automated testing within development and QA environments. However, even with iterative testing, software and system failures do happen.

A Sound Release Management Plan

Sound development, testing, deployment focused on the end user, and system performance are the fundamentals of release management. The release management team of developers, quality assurance teams, and IT system administrators perform activities geared towards successfully completing deployment of software applications. Release management teams must ensure that there is a plan to smoothly recover from deployment calamities. Planning mechanisms focused on documented rollback procedures that effectively enable recovery from deficiencies in deployment.

  • Develop a policy for software versioning. Assign singular version names, singular numbers, or singular digital logic states to each version. Differentiate test versions from release versions with internal version and released version numbering.
  • Test new versions in a simulated production environment. Simulations go far in tying down anticipated functionalities into near-actual performance over time. Modeling the system reveals the key behaviors or functions of physical or abstract processes. The purpose is to demonstrate how processes will respond to real world input, interfaces, stresses, and system commands.
  • Use a build server which extracts data exclusively from the repository. Data in this way is both traceable and reproducible and reduces the risk of code that is outdated and includes undocumented updates. When new coding is checked into the repository, the build server bundles the revised version within the software development environment. In addition, the build server allows deployment of bundles within different environments. Build servers also allow deployment to be executed with a single command.
  • Maintain the configuration management database. To sustain IT installations of data information technology warehouse assets and intellectual properties, as well as data interactions, the configuration management database must be consistently managed and updated.
  • Possibly add an abstraction layer to isolate certain functionalities and thereby separate the concerns of a computer program into distinct sections. The use of abstraction layers in this manner enhances system independence and the ability of a system to operate with other products or systems without restrictions.

Build Servers Over Backups

Backups require sizable computer resources with uncertain success. Backups themselves and backup recoveries are slow and tedious. Backup strategies are also inconsistently verified with source code fundamentals and reliability, as well as with raw data. Recovery with backups mean that there’s a longer user-restricted mode to prevent data from being added. Rollbacks require running transaction log backups in conjunction with recovery rather than quicker and more reliable rollbacks from a build server repository. The delays in recovery with transaction log rollbacks only increase as the size of the database increases.

Automated scripts can be created with build servers, while with transaction log backups, scripts must be manually created and tested. Rollback scripts are some of the most difficult aspects of application development and deployment to create and maintain, especially when data is updated. Maintaining rollback scripts with structural data updates will likely require complex data migration scripts. Finally, when errors are discovered during the release and new transactions are in place, backup rollbacks will cause the loss of data. Rollbacks from build server repositories providing automated updates are much more reliable for system recovery.

More on Abstraction Layers

Branching by abstraction to gradually change a software system to allow releases which are concurrent with changes is a fairly common coding practice. However, the method of introducing change to a system through the use of abstraction layers for the purpose of enabling supporting services to concurrently undergo substantial changes has not always been universally recognized as a rollback facilitator.

Abstraction occurs without requiring changes to front-end coding unless desired. The built-in background database abstraction layer of stored procedures can work on top of the underlying system architecture to accommodate additional parameters (such as version numbers or flags within the rollback routine) to fulfill coding commands while both new and old software versions continue to function. Updates to the structure and the abstraction layer that support structural change allow you to introduce new coding alterations while leaving existing code untouched. Abstraction layers not only smooth deployment but also simplify rollbacks. With abstraction layers, rollbacks merely need to consider how the code path relates to the original functionality, which abstraction layers have left in place.

Abstraction layers do however require a thorough, and preferably automated, test procedure to prevent errors when older code travels through newer abstraction paths. Fundamental database functionalities are retained, requiring consideration of original coding stability.

Blue/Green Deployment

Blue/Green deployments are automated. Automating deployment reduces system resistance and delays. Automated deployments implement Continuous Delivery and Continuous Integration with no downtime and very little risk. From two copies of the database, Blue/Green deployments deploy to one final copy. With two copies in Blue mode, if one copy does not deploy well, there is the option to switch to the second copy, retaining all data. Once you have validated that deployment is fully implemented the application can be switched in Green mode to the database.

Blue/Green deployments simplify rollbacks in that the old database and old coding are never accessed. Even when transactions have occurred after release, immediate switchbacks to the old system can occur, avoiding the restore process or the need for rollback scripts. One of the safest and most efficient deployment and rollback mechanisms are Blue/Green deployments.

Figment Engine

A Blue/Green deployment, however, requires a database that is small enough for two copies of the database to be accommodated on one server. In addition, reliable synchronization or reliable data migration creation and maintenance are required to sync data between databases.

An inherent issue with database deployment is retaining data when failures occur. Combining rollback strategies with Blue/Green deployment can further reduce the risk of failed deployment, as well as better ensure complete and efficient rollback recoveries. Combining strategies allows for more agility and flexibility for stable deployment or required rollbacks.

Rollbacks and the Enterprise

Enterprise requirements for cost efficiency and ROI dictate that software and system business functions are reliable. The length of time required for rollbacks necessarily becomes an enterprise issue. Processing scenarios dealing with database updates, rollbacks, and recompiles are extremely efficient in avoiding and reducing the time required for rollbacks.

Decentralized development even further dictates that the deployment pipeline be standardized per enterprise priorities. Transparency in process and performance, as well as collaboration and enterprise test management, are crucial to communication with management concerns. Diffused independent responsibilities, rather than centralized protocol, place reporting responsibilities and further obligations on developers, QA, and IT administrators to continuously collaborate with business management and stakeholders.

Rollback procedures must be executed within organizational boundaries with a discreet and defensive stance towards possibilities of risk. The process of rollbacks and recovery are direct in process and results. Rollback operators, therefore, bear responsibility for directly communicating processes and collaborating on enterprise priorities in relation to executions. To assure that the rollback process only positively impacts business priorities, thorough and consistent collaboration is imperative between operational concerns and enterprise priorities.

Theoretical or abstract considerations can commonly be overlooked as important for communication to management. However, theoretical rollback considerations can change the import or direction of deployment outcomes, which can pivot the objective away from business goals and priorities. Reliable messaging and reporting, as well as face-to-face collaboration, is crucial within rollback activities.

The spectrum of rollback protocols in free and specialized domains can breathe new life into the stability of software and system interfaces. Efficient rollback strategies reduce costs to the enterprise, enhance deployment time to market, and engage customer loyalty through efficient operations.

Credits: Tgdaily

Credits: Tgdaily

Embedded software systems are usually built into a certain hardware system, and are aimed at the performance of specific functions that help to run a business process successfully and efficiently. Almost every modern device, that is capable of performing a variety of functions, usually come with an efficient embedded software system – hence their helpful and smooth processing nature.

The proper development and up gradation of such a software system is vital for all businesses and organizations, especially the ones who want to walk on a path of success by beating all competition. Finding a software company that comes with experience and reputation in providing high end embedded software solutions, so as to guarantee proper, prompt and efficient service. Today we will take a look at how you can choose the finest embedded software system development solutions. Read on to find out more.

You need to find a software development team that is both flexible and experienced, especially one which has a creative nature and can customize its service based on your needs and specifications. A team with a proper outlook of the future and an inherent ability to innovate based on certain situations occurring in a company are perfect for business organizations who want a software solution that remains in existence for several years. The complications of an embedded software system are directly proportional to the complications of the business world in today’s day and age; hence the team should be able to handle such complications with ease so as to achieve all preset targets.

Industries like the consumer products industry, automotive sector, telecom and wireless industries, multimedia and medical sectors can benefit greatly from an efficient and smooth-functioning embedded software system. Hence, a team that has dealt with almost all of these sectors, and comes with great references and past reviews, should be your first choice.

When any business organization chooses a software development team that adheres to every Safety standardpreset by governing authorities in terms of embedded software system development, they also need to ascertain if the team knows the entire developmental structure. The team should be thorough in its approach, and attentive towards the client’s needs, and should also provide adequate and efficient after sales service and support to all clients.

Why we emphasise on the team’s developmental capabilities is quite simple. This very step can be extremely complicated, and hence requires a lot of attention. There are a few steps that the team needs to take care of to facilitate proper development. They are:

  • Customers requiring thorough analysis
  • Proper architectural design of the software
  • Efficient systems engineering
  • Proper debugging and porting
  • Proper optimization and testing
  • Regular maintenance

Once all these phases are taken care of, the developmental phase becomes a whole lot easy to comply with.

Hence – it is quite simple. When you choose a service provider or a team that deals with embedded software systems, always consider the experience, the capability and the skill set of the team before making a final choice.