Tag Archives: developer

Automated applications deployment: DevOps, no matter what you call it

When it comes to automated applications deployment, is DevOps is a reality for most teams — or just a concept that gets a lot of attention?

There is a new understanding that one size does not fit all when it comes to the business of automated applications deployment. The historic context that puts the responsibility for change and release management in development or operations was in part a response to the needs of the business long ago and to the personalities of the players of the day.

Today many different forces are placing new demands on change and release management, which are stretching traditionally organized teams in a myriad of ways. There is pressure from the development team to reduce controls around code moving from development to unit testing, to user testing, to system testing, to staging. And there is pressure from the business side of the organization to reduce cycle times to keep pace with competitors. In addition, business is making demands around governance and auditing, asking for greater visibility, accountability and traceability.

Whether we call this DevOps or not, all of these things fall under the DevOps umbrella. Software change and release management all over the world has become increasingly important to how organizations conduct business.

Let’s look at the continuous delivery movement. This developer-driven trend automates the movement of code from stage-to-stage of the lifecycle. It automatically provisions the target platforms and requires little human intervention. We trade control and oversight for automation and standardization. The result is that code travels much further down the path to production before anyone intervenes with human checks and balances. This process is much more efficient than keeping developers and testers waiting for changes to move along the process.

How about the mythical "emergency" process? All organizations are experiencing our unplanned code changes — or patches — that are slipped in the at last minute as business demands. What was once about the rare need to remediate a broken technology is now the daily norm for business-critical changes. Unmanaged and unplanned, these kinds of changes will lead to chaos. That’s not something we associate with change and release management.

So, in today’s high velocity world, where revenue generating apps might undergo several "turns" of changes every month, there is a renewed focus on release management.

Source: http://searchsoftwarequality.techtarget.com/answer/Automated-applications-deployment-DevOps-no-matter-what-you-call-it

Did you like this? Share it:

Apple Is Beta-Testing An Update That Kills Evasi0n Jailbreak

All good jailbreaks must come to an end.

Late last week Apple released an update for iOS to developers in beta that prevents the use of the popular jailbreak software evasi0n, according to one of evasi0n’s creators who tested the patch over the weekend, David Wang.

Wang tells me that he’s analyzed the 6.1.3 beta 2 update and found that it patches at least one of the five bugs the jailbreak exploits, namely a flaw in the operating system’s time zone settings. The beta update likely signals the end of using evasi0n to hack new or updated devices after the update is released to users, says Wang, who says he’s still testing the patch to see which other vulnerabilities exploited by the jailbreak might no longer exist in the new operating system.

“If one of the vulnerabilities doesn’t work, evasi0n doesn’t work,” he says. “We could replace that part with a different vulnerability, but [Apple] will probably fix most if not all of the bugs we’ve used when 6.1.3 comes out.”

That impending patch doesn’t mean evasi0n’s time is up, says Wang. Judging by Apple’s usual schedule of releasing beta updates to users, he predicts that it may take as long as another month before the patch is widely released.

When evasi0n hit the Web earlier this month, it quickly became the most popular jailbreak of all time as users jumped at their first chance to jailbreak the iPhone 5 and other most-recent versions of Apple’s hardware. The hacking tool was used on close to seven million devices in just its first four days online.

Despite that frenzy, Apple has hardly scrambled to stop the jailbreaking.  Evasi0n has already gone unpatched for three weeks. That’s far longer, for instance, than the nine days it took Apple to release a fix for Jailbreakme 3.0, the jailbreak tool released in the summer of 2011 for the iPhone 4, which was by some measures the last jailbreak to approach Evasi0n’s popularity.

Apple’s slow response to Evasi0n is explained in part by the relatively low security risk that the tool poses. Unlike Jailbreakme, which allowed users to merely visit a website and have their device’s restrictions instantly broken, Evasi0n requires users to plug their gadget into a PC with a USB cable. That cable setup makes it far tougher for malicious hackers to borrow Evasi0n’s tricks to remotely install malware on a user’s phone or tablet.

Security researchers have nonetheless pointed out that Evasi0n could give criminals or spies some nasty ideas. The tool uses five distinct bugs in iOS, all of which might be appropriated and combined with other techniques for malicious ends. And F-Secure researcher Mikko Hypponen points out that if a hacker used a Mac or Windows exploit to compromise a user’s PC, he or she could simply wait for the target to plug in an iPhone or iPad and use evasi0n to take over that device as well.

More likely, perhaps, is a scenario described by German iPhone security researcher Stefan Esser. He argues that a hacker could use a secret exploit to gain access to an iPhone or iPad and then install evasi0n, using the jailbreaking tool to hide his or her tracks and keep the secret exploit technique undiscovered by Apple and unpatched. “That way they protect their investment and leave no exploit code that could be analyzed for origin,” Esser wrote on Twitter.

Apple already has a more pressing security reason to push out its latest update. The patch also fixes a bug discovered earlier this month that allows anyone who gains physical access to a phone to bypass its lockscreen in seconds and access contacts and photos.

When Apple’s update arrives, the team of jailbreakers known as the evad3rs may still have more tricks in store. Wang tells me that the group has discovered enough bugs in Apple’s mobile operating system to nearly build a new iOS jailbreak even if all the bugs they currently use are fixed.

But then again, Wang says he hasn’t yet been able to check Apple’s patch for every bug it might fix–either the ones evasi0n employs or those he and his fellow hackers had hoped to keep secret for their next jailbreak. “If they patch most of the bugs,” Wang says, “Then we’re starting from scratch.”

Source: http://www.forbes.com/sites/andygreenberg/2013/02/25/apple-is-beta-testing-a-fix-for-evasi0n-jailbreak/

Did you like this? Share it:

Code signing: Stamp of approval for Android and iOS apps

An application security technique known as code signing is gaining importance as the Apple and Android mobile distribution centers require developers to provide the apps they write with a stamp of approval.

Code signing indicates that "you know where the code came from and it hasn’t been corrupted," said August Detlefsen, a security consultant for AppSec Consulting, in San Jose CA.

"The purpose is to basically guarantee that when you get some code, you know who it’s from," said Frank Kim, principal of security consultancy ThinkSec and curriculum lead for application security, SANS. "It’s to give you some level of trust."

Mobile application distributors use code signatures to help prevent malicious code from being distributed among mobile devices. "Both iOS and Android enforce the fact that your code must be signed in order to distribute it through the App Store or Google Play Store, so in order to get your software out there, you must sign it so that at least the identity of the person who created the code is verified," Detlefsen said.

Apple goes a step further and adds its signature to the applications distributed via its App Store. Before any code runs on an iOS device — assuming it hasn’t been jailbroken — the device verifies the signatures. This helps ensure the code has not been modified.

Developers who submit code for distribution via Apple’s App Store don’t have to be concerned with the details of code signing. "When I register for the iOS development program, it’s pretty straightforward," Kim said. "Apple makes the process as seamless as possible."

In other scenarios, the process of code signing is a bit more involved. "If you’re developing other types of software, server-side apps, or those distributed to enterprise customers in a different way, then it’s more cumbersome because the infrastructure is not there," Kim said.

Code is signed using public key cryptography. The process begins with the generation of a cryptographic hash. This is done by running the source code or compiled executable through a one-way function that calculates a checksum based on the bits in the code, Detlefsen explained. The resulting cryptographic hash is unique and non-reversible. The hash is sent through another cryptographic function along with a unique key known only to the user, resulting in a signature. It is a short alphanumeric string that is associated with the code. A public key, associated with the private key but freely sharable, can be used to verify the code is signed with the private key by running the signature and the corresponding public key though a signature verification function.

Public and private keys can be generated at no cost using one of the many key generator tools that can be found online, Detlefsen said. However, these keys do not offer verification that you are who you say you are. After all, Detlefsen pointed out, "Just because the code is signed doesn’t mean that the [developer of that code] knows what they’re doing."

An alternative is to purchase keys from a certificate authority, like VeriSign or DigiCert. These companies validate the identities of their customers. Information such as the signer’s name and organization is included with the code signature, and can be verified with the certificate authority.

There are no risks involved with the code signing process itself. However, the private key must be kept private. If an attacker were to obtain the private key, he could modify the code and sign it with the private key, leading people to believe the code came from a trusted source when in fact it did not.

While developers benefit from signing their own code, they also benefit from the signatures on the code they use. "A lot of developers use third-party code and open source libraries. If you’re building significant apps that require security, you should also check the authenticity of the code you’re using," Detlefsen said. An attacker could insert malicious code into an open source library. "Code signing provides one way of knowing that the code you’re downloading is verified to be the original and hasn’t been tainted in some way," he said. "Before you run it, verify the signature."

But not all code is signed in the first place. "Code signing is becoming more well-known and practiced because these distribution centers are requiring it. But as far as code you download over the Internet, or let’s say there’s an applet in your website or a flash app on a website, you might not know where it came from or whether it was something the original developers put there," Detlefsen said.

Source: http://searchsoftwarequality.techtarget.com/news/2240176128/Code-signing-Stamp-of-approval-for-Android-and-iOS-apps

Did you like this? Share it:

Agile Developers Needed, Demand Outpaces Supply: Study

The number of available agile jobs outnumbered qualified candidates by nearly 5 to 1 over the last two years, according to a study by Yoh Services.

As more and more enterprises begin to adopt agile software development methodologies, the need for qualified agile developers has skyrocketed. However, the number of available agile developers cannot keep up with demand, according to a recent study.

Many of the Fortune 500 and leading brands in America are increasingly searching for agile software developers that can help them improve speed of delivery and provide more and better value to their customers. Yet a study conducted by staffing firm Yoh Services based on data from CareerBuilder’s Supply and Demand Portal revealed that the number of advertised agile jobs outnumbered active candidates by 4.59 to 1.

This skills gap has not only made it difficult for companies to quickly source quality talent on demand, but also puts them at risk of hiring technical professionals that have poor agile methodology skills. At the same time, as more companies seek to capitalize on agile practices, many agile professionals struggle to find an established program that fits their abilities.

Agile software development refers to a group of software development methods based on iterative and incremental development, in which requirements and solutions evolve through collaboration between self-organizing, cross-functional teams. It promotes adaptive planning, evolutionary development and delivery, a time-boxed iterative approach, and encourages rapid and flexible response to change.

Agile methods break tasks into small increments with minimal planning and do not directly involve long-term planning. Iterations are short time frames or "timeboxes" that typically last from one to four weeks. Each iteration involves a cross-functional team working in all functions: planning, requirements analysis, design, coding, unit testing and acceptance testing. At the end of the iteration, a working product is demonstrated to stakeholders. Agile development emphasizes working software as the primary measure of progress.

The Yoh analysis showed that companies advertised a total of 558,918 agile jobs from 2010 to 2012. During the same time period, there were merely 121,876 active candidates, just 17 candidates for every 100 jobs. Inconsistencies in experience and geography compound this "agile gap," the Yoh study showed. Of the available job seekers, more than 50 percent have 10 years of experience or more, while less than 2 percent have one to two years of experience.

The agile gap exists across the U.S., varying only in its degree of severity. For instance, while states like Florida and Texas have a higher average number of active candidates, the ratio of open positions to candidates remains high, at 4 to 1. States with a more severe gap, however, such as Washington and California, have 10 open positions for every candidate, the study revealed.

The adoption of the agile development methodology has accelerated since the latter part of the last decade, while training for frontline developers failed to keep pace. As a result of the high demand for a limited number of agile developers, many industries, such as computer systems design services, custom computer programming services and software publishing, struggle to attract the agile talent they need. Organizations that get available, experienced talent are forced to pay premiums, whereas others are forced to hire and train professionals on agile methodologies.

"These discrepancies can hurt the hiring companies in the form of increased costs, salaries and turnover," Don Hanson, senior vice president of the eastern region at Yoh, said in a statement. "When companies hire the wrong candidate, they jeopardize employee engagement as well as potentially damage their reputation in the agile community, hurting future recruiting efforts. More than ever, a thorough vetting and hiring process is crucial for both agile employers and job seekers."

For this reason, "agile developers hold all the cards," Bob Schatz, chief agile evangelist at Yoh and owner of Agile Infusion, an agile coaching firm, said in a statement. "As demand for agile skills continues to grow, employers must clarify the extent of their agile programs, whether they’re established, new, or still just an idea.

"By erring on the side of transparency about the state of the company’s agile culture, employers will be able to find the best talent for their open positions and avoid turnover costs as well as misunderstandings during the hiring process that could alienate future agile recruits," he said.

Yoh, a Day & Zimmerman company, sought insight into the state of the agile talent pool as demand continues to rise for agile practitioners, who build software and transform business processes through teamwork; customer collaboration; short, iterative cycles; and responses to change. As more companies seek a nimble and entrepreneurial approach to business, the agile development methods of companies like Facebook and Apple are quickly spreading, but a lack of educational resources has left few agile practitioners to fill that need, Yoh officials said.

"Given the gap between available talent and demand, companies seeking to hire an agile team must understand that the adoption of agile development requires a complete change in culture, and they must make that transition or risk high turnover, lower morale, and loss of credibility in the agile community," Schatz said in a statement.

For more information on the agile skills gap, the positions most in demand and the companies most in need of agile talent, check out Yoh’s infographic.

Source:   http://is.gd/2GrocC

Did you like this? Share it:

Mastering UI for Beginners

You know the situation: you’re about to get on an airplane for five hours and you just hope to not get stuck next to the loud snorer or the crying baby. Fortunately for me, my last flight yielded a more interesting fellow traveler.

As I was beginning to nod off around 20,000 feet, I noticed out of the corner of my bleary eyes that my seatmate blueprint_uiwas tapping away on an iPad app that I had never seen before. My fellow flyer was actually using Blueprint, an iOS UI design tool. After striking up a conversation, I learned that the man busy toiling in app interfaces was no master developer but rather a middle school teacher who had an idea or two.

Frustrated with a manual methodology for tracking students in his classroom, he began jotting ideas on napkins on how to make the process more efficient by creating his own app. He tracked down a developer and got to work. After a successful launch in the Apple App Store, my new acquaintance is now on the path to creating his next app. This time though, he is using the more refined method of Blueprint to map out his idea.

This amazes me. The power to create and design apps isn’t just for developers anymore. Now it is within reach of the everyman. No longer can someone sit on the couch, watch a commercial and say, “well, yeah but I thought about that five years ago.” Instead, they can take matters into their own hands (or finger tips!) and start designing.

Now, with the help of tools like Blueprint, App Cooker and iMockups, developers can gain clear guidance from passionate consumers with great ideas. Here’s to the people and the potential for exciting apps in the future.

source: http://blog.utest.com/mastering-ui-for-beginners/2012/07/

Did you like this? Share it:

Google Outsells, but Apple Cultivates Loyalty of App Developers

Smartphones running Google’s Android operating system outsell iPhones more than two to one. And yet, even as Google’s system has gobbled up market share, Apple has held onto one critical advantage — the loyalty of mobile app developers.

Many developers have continued to make applications first, and sometimes only, for iPhones. They find it easier to create software for Apple devices than for ones running Android, or it may be more lucrative. Their allegiance to Apple has helped make its devices the powerhouses they are for the company.

“Android may have a lead in how many handsets it ships, but it doesn’t have a lead in how much money app developers are making from it,” said Hadi Partovi, an investor in technology start-ups like Dropbox and a former manager at Microsoft.

On Monday, Apple will seek to strengthen its ties to mobile developers with a series of product announcements on the opening day of its developer conference in San Francisco, an annual ritual where the company tries to stimulate the creative juices of this important constituency. The company is expected to introduce a new version of the iOS operating system that powers iPhones and iPads, according to people familiar with Apple’s plans who were not authorized to speak about them publicly.

One feature of that software is expected to be an eye-catching new 3-D map service operated by Apple that will pose a challenge to a Google map service used within many iPhone applications, these people said.

“It’s a lot more beautiful,” said one of these people, who has seen a demonstration of Apple’s maps service.

At the same time, Apple is expected to update its Mac family of computers with new hardware, these people said.

Natalie Kerris, an Apple spokeswoman, declined to comment.

The conference is “the most important event of the year,” said John Casasanta, owner of Tap Tap Tap, the software studio that makes the popular Camera+ app, available only on the iPhone. “I’m having trouble thinking of any conference that comes anywhere near as relevant.”

Apps are among the strongest weapons Apple and Google have for marketing their mobile technologies to consumers. The bounty of software available for Android and iOS, as varied as racing games and apps for managing recordings on cable boxes, is a chief reason the mobile phone market has settled into a two-horse race.

Rival technologies plagued by a scarcity of apps, including Research in Motion’s BlackBerry and Microsoft’s Windows Phone, are finding it difficult to persuade developers to invest in them.

Apple’s continued influence among mobile app developers flies in the face of predictions that the company would steadily lose clout as Android phones flooded the market, presenting developers with a much bigger target audience. And it could help Apple avoid the fate the Macintosh experienced in the 1990s when competing with PCs running Microsoft’s Windows operating system.

Although many considered the Mac to be superior, Microsoft outsold Apple’s computers in part by distributing its product broadly on hardware made by many companies, which helped Windows to snowball.

Software developers flocked to the larger Windows PC market, which in turn attracted more customers, which attracted still more software developers to Windows. For the better part of two decades, Microsoft held the allegiance of software developers, relegating the Mac to the periphery of the computer business.

In the mobile market, there is no doubt Apple’s share has been overshadowed by Google, which makes Android freely available to any hardware maker that wants to build a phone with it.

Although the first Android handsets did not appear until about a year after the iPhone was released, widespread support from handset manufacturers, especially Samsung, and wireless carriers helped propel Android to 59 percent of the smartphone market during the first quarter, compared with 23 percent for the iPhone, according to estimates from IDC, a research firm.

There have been predictions that the huge volume of Android smartphones being sold would persuade developers to abandon or at least weaken their iPhone efforts by, for example, developing apps first for phones running Android.

In December, Eric Schmidt, the executive chairman of Google, said that six months from then, mobile developers would begin favoring Android app projects over iPhone apps.

“Because ultimately applications vendors are driven by volume and the volume is favored by the open approach Google is taking,” Mr. Schmidt told an audience at a technology conference in Paris.

That six-month mark passed last week. In the interim, the companies behind some well-known iOS apps like Instagram have made Android versions of their software. But as the technology writer and investor M.G. Siegler wrote in a column on TechCrunch last week, Mr. Schmidt’s prediction that developers would begin making Android apps first did not come to pass, at least not the most prominent developers.

“You failed hard in this prediction,” Mr. Siegler wrote, addressing Mr. Schmidt.

Christopher Katsaros, a spokesman for Google, declined to comment for this article.

Developers say it is easier, and therefore less costly, to develop apps for the iPhone than for Android phones, in part because there are far more models of Android phones in use, with different screen sizes, processors and other technologies.

The variations in hardware and software are not insurmountable obstacles, developers say, but performing the testing to ensure that apps run properly on most Android phones adds time and cost.

“Writing apps consistently across all of them is really hard,” said Nat Brown, an independent iOS developer in Seattle who has created a line of children’s apps for the iPhone.

Mr. Brown also said he periodically considered writing Android apps, but had decided against it in part because iPhone users have demonstrated a higher willingness than Android users to pay for apps.

Flurry, a mobile analytics firm, published a report last week that estimated that for every $1 a developer brought in for an application on iOS, he could expect to take in about 24 cents on Android.

“Apple is almost the default first platform you develop for and then you develop for Android,” said Rob Cihra, an analyst at Evercore Partners.

Furthermore, Apple has been far more effective in getting iPhone users to update their phones with the latest version of iOS than Google and its partners have with Android. This makes it easier for iPhone developers to write their apps because there is less variation in the underlying software on the devices.

One other advantage Apple has among developers is the iPad, which has so far maintained its dominance in the tablet category, despite challenges by an assortment of Android tablets. Because the iPhone and iPad use iOS, it is relatively easy for developers to adapt their software to run on Apple’s tablet, significantly expanding the audience of potential customers beyond the iPhone.

It is difficult to say whether Apple’s position with developers will remain strong if Android continues to gobble market share. But various surveys have tried to gauge which smartphones developers plan to write apps for in the near future, and the iPhone often scores very high.

Still, Google is closing the gap between the sheer number of apps for Android, which stands at about 500,000. Earlier this year, Apple said there were 600,000 apps in its App Store.

One occasional source of discontent among Apple’s developers is the greater control that the company exerts over its App Store, for which it takes a more hands-on approach to approving software for distribution than Google does.

Paul Kafasis, the chief executive of Rogue Amoeba Software in Boston, has had a couple of run-ins with Apple over iPhone apps that Apple initially rejected for different reasons. Most recently, Apple objected to a function in an iOS app, Airfoil Speakers Touch, that allowed users to listen to music streamed from a song library on iTunes and other Apple devices.

Mr. Kafasis modified the function in the app, which Apple then allowed to be sold. While he chafes at the gatekeeper function Apple performs, he said he had no plans to develop products for Android.

sourcing:http://www.nytimes.com/2012/06/11/technology/apple-keeps-loyalty-of-mobile-app-developers.html?_r=1&pagewanted=all

Did you like this? Share it:

Top 7 dilemmas facing today’s developers

Your boss wants it yesterday, but it better be good when judged by the standards of tomorrow. Your customers want every feature they can imagine, but don’t you dare confuse them by giving them all the buttons they want. Your fellow programmers want your code documented, but they just respond "tl;dr" to anything you write.

As technology evolves, so too do the dilemmas developers confront. Every choice, from platform to data store to how much control to give your users, is fraught with questions. And thanks to the cloud, the rise of mobile tech, and the hastening cutting edge, it seems as if the programming world faces a new choice — and dilemma — at an increasing pace.

Packaging your problems and giving them a name can help you manage them and maybe even find solutions, or so they say. Toward that end, here is a list of the most significant dilemmas facing programmers today. It is by no means complete — then again, what project related to application development ever is?

Got another dilemma? Add it to the comments.

Developer dilemma No. 1: When to say when on feature requests
If we had a dollar for every feature our customers wanted, we’d still be broke because that would require building an accounting system that matched each dollar with each feature. These would then need to be cross-linked and prioritized because our customers would also demand a sophisticated bug/feature management system for their dollar. Then the database of wanted features would need to be backed up to some cloud and translated into every language.

This is the dilemma: Everyone wants feature-rich code, but no one wants to pay the cost of managing all of it. Anyone who’s tried to build something as simple as a four-button remote control app knows how many zillions of designer years it takes to create something that simple. Making something elegant requires sweat that soaks through everything.

Consumers, the marketing department, sales reps in the field — it doesn’t matter who makes the request. Giving them the button they want may actually be the worst thing you can do for them. Suddenly there might be too many buttons and too much confusion about what each button does. The ideal is to make something easy enough to understand intuitively, but alas, creating something intuitive for those who are prone to ask too much of their software is all but impossible.

You’ve tried quoting the old "rule of 10,000" to your boss. This states that anything worth doing requires at least 10,000 hours of work to become competent. That just brought a laugh because that app store customer or coworker in accounting is going to spend more time drafting a nasty review or email than trying to understand the features you’ve collected in your app, even if they’re features the users said they want.

Sadly, the ideal can often be to convince your customer they don’t actually want the feature they’ve requested. After all, Twitter continues to offer a feature-poor system that imposes a 140-character limit, laughable in the era of terabyte disk drives. Yet it sails on, serene in the knowledge that all those attempts at providing new features are examples of trying too hard.

If only this solution to the dilemma of unending feature requests was available to us all.

Developer dilemma No. 2: How much documentation is enough?
I was sitting in a meeting with an aggressive project manager who really wanted to stick it to a competing project manager. This manager promised that the code coming out of his team would have "documentation," he said, before pausing like James Bond introducing himself and saying, "Extensive documentation."

The only thing worse than no documentation is a bookshelf filled with binders stuffed with extensive documentation. Some project managers love to measure their progress by the pound, and they see more words as better words. Anyone who’s slogged through "Moby Dick" in high school English knows the feeling.

We want to know information about the code, but no one has an acronym for Too Little Information. Everyone on Facebook knows the initials TMI.

There is no easy answer for the programmer. Ideally, the code is clean enough and self-documenting enough to avoid the need for long paragraphs explaining just what the code is doing. Code-based documentation doesn’t get left behind like text documentation when someone rewrites the code but doesn’t get around to the text.

There is hope that an even smarter collection of debuggers and code-analyzing compilers will be able to do a better job understanding our code. The latest versions of the virtual machines keep copious records of which routines are executed. While most of the emphasis is on performance, this kind of meta data can be more useful than real documentation by identifying when data is changed.

But it will be years before we can drink the Kool-Aid and dream about artificial intelligence understanding our code. For now, we’re stuck with the problem of how to create just enough documentation to keep everyone happy without shortchanging the feature set.

Developer dilemma No. 3: To the cloud, or not to the cloud?
It’s so much easier to call up a new server from the cloud than to fill out a requisition form and ask the server maintenance folks to buy a new one. You push a button and you have your own server.

Alas, this approach can be costly. The servers may be only a few pennies for an hour, but they add up when everyone wants their own cluster for each project. The next thing you know, there are hundreds of servers in the cloud, most of them created by people who left for other jobs several years ago. It’s cheaper to keep paying the bills than to figure out what they do.

To make matters worse, the servers aren’t your own. Some companies are famous for writing terms of service that are very one-sided, claiming, for instance, the ability to shut down your machines for "no reason." That seems to be changing as cloud vendors recognize that such overreaching drives away the customers with the most money. But no one knows what happens if you encounter problems in the cloud. Sometimes it helps to control the paycheck and retirement funds of the person responsible for the server staying up.

The more you outsource, the more you lose control and spin your wheels trying to recapture it. The less you outsource to the cloud, the more you spin your wheels keeping everything running.

You’re damned if you do, damned if you don’t.

Developer dilemma No. 4: Maintain old code, or bring in the new?
One of the deepest challenges in running an enterprise stack of software is deciding when to stick with the old and when to switch to the new. Every line of code in the stack is getting older by the minute, and while you might not think so, the reality is that software manages to find a way to go bad, little by little.

The old code really does stop working. Partners start offering slightly different services and sometimes stop supporting features altogether. Twitter, for instance, locked out people who used its old API when the company started insisting on using the OAuth API. These stories are repeated again and again.

The trouble is that replacing the old with the new can be expensive. Programmers of the new are usually forced to maintain compatibility with old code, a challenge that often requires writing two programs: one filled with the old bugs and one filled with new ones that haven’t been discovered yet.

To make matters worse, the new code is often held to higher standards. I’ve seen new fancy AJAX masterpieces that run much slower than old green-screen mainframe code all because they have fancy buttons and tons of images that push the video card. The look is slicker, but the feel is slower.

There is no easy answer to this dilemma. The old code still works. We like it. It’s just that it’s not compatible with the new version of the operating system or a new multicore chip. The new code costs money. We can usually fix a number of glaring problems with the old code, but who knows what new problems might appear?

Developer dilemma No. 5: SQL vs. NoSQL
There is one big challenge for the database administrators of the world: stick with tried-and-true SQL or switch to trendy NoSQL where everything is bigger and ready for endless streams of data.

The new NoSQL databases sound attractive. They can be much faster than older databases, and they often force users to avoid many of the problems that caused so much trouble in the first place. JOINs, for instance, can slow down a database if the schema gets too complicated. NoSQL tosses them out the window along with many parts of the schema. You can store any key-value pair you like, and the NoSQL database will come up with the answer.

But if you look closely, the NoSQL databases aren’t always so wonderful. First, they often don’t offer guarantees that the data will be recorded. It probably will be OK, but not if something happens to a hard drive or a computer in the cluster. Some of the newer NoSQL options from companies like Oracle allow you to ask for a transaction confirmation, but your code will need to twiddle its thumbs and wait just like the code that uses a SQL database.

There are deeper issues. Many of the speed problems came about because programmers didn’t think about the subtle effects of SQL. The way you structure your tables and queries can make a big difference in performance. Linking together multiple tables and forcing the database to JOIN the information slows things down.

But if you try to accomplish the same thing with a NoSQL database, you’ll often be writing data in and out of multiple places and hoping it will all stay consistent. You get to do all of the work of JOINing disparate sections of the database, and that probably means you’ll pay the cost in speed. If you are aware of this and are able to think through the trade-offs when designing code, you’ll be OK. But if you’re not, you may find that your code is even slower and buggier. The database won’t enforce the transactions, and you’ll need to do it yourself.

This dilemma has a simple answer: Applications that need better consistency should rely upon the transaction guarantees of older SQL machinery. Applications that need speed and can handle a few scrambled records can choose the newer NoSQL datastores. But if you need speed and consistency, you might as well start pulling out your hair.

Developer dilemma No. 6: Go native, or target the mobile Web?
In the beginning, Apple wasn’t going to let anyone develop apps for the iPhone. If you wanted to target the iPhone, you needed to write HTML5 for Safari. It was an elegant answer with a well-understood sandbox for developers to use.

Alas, no one was happy with the locked-down platform. People wanted to write native code, a pathway certainly essential for fast games and useful for slower applications that let you browse information. Apple relented, and now we have the App Store.

The trouble is that the code for the iPhone won’t work on other smartphones and vice versa. Any company that wants to target multiple manufacturers must rewrite their application — a long, slow process prone to incompatibilities. Plus, it’s double or triple the work.

HTML5 is a nice option. If you can write your application as a Web page, there’s a good chance your users can pop them open in the smartphone’s browser. There are already a number of great frameworks that make this a bit smoother.

The trouble is that it’s not necessarily in the interests of the smartphone manufacturers to embrace this interoperability. If the phones are going to stand out, they’ll need to offer something special, and that usually means something different. That won’t happen if everyone runs the same HTML5 apps.

There are plenty of rumors that the performance of HTML5 on the smartphones is not as good as it could be. Some suggest that the HTML5 engines are a bit slower. There is no easy way to test this or even understand the motivation behind any sloggy code. In many cases, the HTML5 is slower because it’s interpreted instead of compiled directly for the hardware.

The answer to this dilemma is guessing how important performance will be to your mobile app. If it’s essential, then custom-compiled native code is the answer. If it isn’t, you have some leeway to explore HTML5.

Developer dilemma No. 7: How much control should users really get?
Software users are like teenagers, it’s said: They want all of the freedom they can get, but they expect you, the good parent, to rescue them from harm. They want all of the advantages of the walled garden, but insist on being able to slip through some backdoor whenever it suits their fancy.

The issue of control is a difficult one for programmers. The ethos of open source permeates the culture, with its insistence that everyone should be able to recompile the stack and tweak anything to fit. Alas, the average user can’t make use of this power no matter how much they want it. Even most programmers have to spend hours finding the right versions of the libraries and the latest edition of the compiler. Control means nothing if you don’t have the time to use it.

Some companies are pushing the ideal of open databases. We’re all supposed to be able to download the information about us. Alas, most of us can’t do anything with the information, and the only ones with the time and energy to use these open doors are other companies.

There is no answer to this dilemma. If you give your users control, they’ll complain about the UI and the features they didn’t get. If you don’t, they keep nagging you for it.

Source:

http://www.javaworld.com/javaworld/jw-05-2012/120521-top-dilemmas-for-developers.html?page=1

Did you like this? Share it:

Introducing LocalDB, an improved SQL Express

Introduction

It gives me great pleasure to introduce a new version of SQL Express called SQL Express LocalDB.

LocalDB is created specifically for developers. It is very easy to install and requires no management, yet it offers the same T-SQL language, programming surface and client-side providers as the regular SQL Server Express. In effect the developers that target SQL Server no longer have to install and manage a full instance of SQL Server Express on their laptops and other development machines. Moreover, if the simplicity (and limitations) of LocalDB fit the needs of the target application environment, developers can continue using it in production, as LocalDB makes a pretty good embedded database too.

Background

Before focusing on technical description of LocalDB, I’d like to provide some background on the direction we took building it.

Today SQL Server Express serves two distinct needs. On one hand it is a free edition of SQL Server. The installation, management and programming of SQL Express in this role is expected to be 100% compatible with other editions. It can be used for learning, training and to run relatively small production database (with less than 10GB of data). Upgrade from SQL Express to paid SQL Server editions is a matter of typing in a license key and no installation is required.

But SQL Express is also SQL Server edition for developers writing applications targeting SQL Server. In this role the programming of SQL Express is still expected to be 100% compatible with other SQL Server editions, but SQL Express is supposed to be small, simple, low-footprint, require no configuration or administration, run as non-admin user, etc.

Our approach so far was to try to make SQL Express perform well in both roles. But as SQL Server product matured, and in effect added more complexity, it became harder and harder for SQL Express to be both compatible with other SQL Server editions and small/simple. The challenge is most visible in installation and configuration of SQL Express. In SQL Server "Denali" we decided to change the approach it and introduce a dedicated version of SQL Express for developers – LocalDB that delivers the simplicity and yet is compatible with other editions of SQL Server at the API level.

Also, by making LocalDB a better SQL Express for developers, we hope to be able to improve the regular SQL Express to be a better free SQL Server. We’d be very happy to hear your feedback in this area, especially if you’re using SQL Express as a database server and find any issues caused by the new features that were introduced to fit the needs of developers and desktop environment.

Source: http://blogs.msdn.com/b/sqlexpress/archive/2011/07/12/introducing-localdb-a-better-sql-express.aspx

Did you like this? Share it:

Unit Testing is a Means to an End

Most professional software developers these days understand the importance and value of writing and using unit tests. A nice summary of some of the oft-touted and oft-realized benefits of unit testing can be found in the StackOverflow.com thread Is Unit Testing worth the effort? [my only very minor criticism is the mixing of more specialized Test-Driven Development (TDD) with the more general unit test concept]. As with most good things, however, even unit testing enthusiasm can go too far. The benefits of unit testing can lead to overly enthusiastic unit testing developers forgetting that unit tests are not the end themselves, but rather are a means to the real end.

The "end" that most software developers are striving for is delivery of software solutions that make their users’ lives easier and more productive. Unit tests can be extremely valuable in obtaining this end and certainly add to software quality, but the overly zealous unit tester must beware of allowing the unit tests themselves to displace this end goal. It’s all too easy to allow oneself to get so bound up in writing exhaustive and "perfect" unit tests that one puts the true end goal at risk. In the remainder of this post, I look at ways in which developers can allow unit testing to move from helping achieve the desired end to unintentionally displacing the real end and putting it at risk.

Overreaching Unit Testing

Steven Sanderson has written "the benefit of unit testing is correlated with the non-obviousness of the code under test." I largely agree with this sentiment as a general guideline. I see little value in unit testing trivial "get" and "set" methods. Some methods are more readily evaluated via code review than via unit test.

The concept of code coverage can be a useful one as long as it’s not taken too far. Code coverage appears to provide high return for the effort for a while, but there comes a point of diminishing returns when gaining additional code coverage comes at much greater cost and may not be worth that cost. It’s also important to recognize that even the often highly expensive 100% code coverage typically means only all lines of code were executed and does not check all possible paths through the code.

All Code’s Unit Testability is Not Equal

The post Selective Unit Testing – Costs and Benefits clearly articulates well the differences in difficulty (cost) and advantages (benefits) of unit testing of different types of code. In cases where the advantages/benefits of a unit test are high and the cost/effort is low, the value of unit testing is obvious. On the opposite extreme, there are types of code that receive little benefit from unit testing.

Source: http://www.javaworld.com/community/?q=node/8354

Did you like this? Share it:

Amazon is No. 1. Who’s next in cloud computing?

Amazon Web Services is, by all accounts, the largest cloud service provider by far, although good luck finding third-party numbers to verify that. Amazon, like most of the big cloud providers, doesn’t disclose much about current or planned data centers.

New research from Accenture analyst Huan Liu estimates that Amazon’s Elastic Compute Cloud (EC2) runs on a whopping 450,000 servers. Amazon does not break out AWS revenue, but some say it could already be a billion dollar business.

So, stipulating AWS as No. 1, here are seven cloud rivals that could give it a run for its money over the next few years.

1: Rackspace: While Rackspace encompasses managed services and pure hosting businesses, it’s also a major cloud provider with actual, paying customers.  Measuring by revenue and VMs, Rackspace currently has a lock on the No. 2 slot by a wide margin, said Gartner analyst Lydia Leong. As one data point, Rackspace public cloud revenue rose to $189 million in fiscal year 2011, up from $100M the previous year. Going forward, that business should only grow as Rackspace brings more OpenStack implementations online.

2: Google: If you’re talking number of physical servers, Google could already be the biggest cloud player. As for paying customers? That’s harder to discern. Google is one of the few companies that can (and does) invest in the pure computing firepower to contend with AWS. If you count all that Google Apps and Gmail storage, then Google’s obviously a huge player. The Google App Engine platform-as-a-service is still around but isn’t a factor for business developers.

3: Microsoft: Two-year-old Windows Azure has big capacity, but actual traction is unclear — but it is clear Microsoft is going for the gusto. Microsoft just launched an Azure-focused startup accelerator in Israel to help boost demand. Next week, it is expected to announce timing for the first of its ERP products — actually the first of any of its major products — to run on Azure. And, going forward, Microsoft Azure’s embrace of Hadoop could attract more of the next-generation big-data workloads that the cloud vendors compete for.

4: IBM: IBM SmartCloud is coming up fast on AWS and Rackspace even now, according to one cloud storage expert. That news surprised me but probably shouldn’t have, given IBM’s size and resources. And face it: IBM knows data centers. Like Microsoft, it is bringing Hadoop into its cloud with its InfoSphere BigInsights service.

5: Hewlett-Packard: HP’s been all over the map on cloud plans, promising an Azure-based implementation a few years ago that has gone nowhere and more recently standing up an OpenStack-based public cloud. Zorawar “Biri” Singh, SVP for HP cloud services, told the New York Times last week that HP’s cloud will add features and capabilities beyond what AWS provides.  HP has also said it wants to challenge AWS for the hearts and minds of cloud developers. HP has had its share of woes lately, but it’s still a tech power, and provided the cloud is a priority with new management, it would be hard to rule out.

6: VMware: VMware’s vCloud already runs a ton of clouds for third-party providers, and the company’s Cloud Foundry platform-as-a-service is gaining traction. All of that plus the Mozy cloud storage service, which VMware manages for parent EMC, means that the company — which dominates server virtualization inside the firewall — is gaining a pretty impressive toehold in the cloud beyond as well.

7: Facebook: Don’t laugh. It’s a wildcard, but Facebook is putting serious sweat into data centers. And it’s applying lessons learned to the Open Compute Project, which aims to apply open source development to hardware design. With more than 800 million users, Facebook knows a thing or two about cloud infrastructure. True, Facebook doesn’t offer cloud services now, but then again, Amazon used to just sell books. Facebook could evolve into many things. GigaOM’s Derrick Harris has already suggested that Facebook could be your next software vendor.

Source: http://gigaom.com/cloud/amazon-is-no-1-whos-next-in-cloud-computing/

Did you like this? Share it: