OK, Enough with the 'as-a-Service' Acronyms

I'm starting a Friday Afternoon Rant-as-a-Service (FARaaS) because I can't take any more "as-a-Service" acronyms. Things have gone too far. Every time I see a new one, I cringe.

Today I cringed in learning about a Proof of Concept-as-a-Service (POCaaS) offering from InterCloud Systems, referring to a new service to test software-defined networking (SDN) and network functions virtualization (NFV) technologies.

Apparently anyone can just start using any "as-a-Service" acronym they can think of and hope it gets picked up. I just might ditch this job and start doing that full time, providing Acronyms-as-a-Service (AaaS) -- though As-A-Service-Acronyms-as-a-Service (AASAaaS) would be fun, too, just hard to capitalize correctly.

Anyway, Intercloud is adding PoCaaS to its already impressive arsenal of acronyms it advocates, including Software-as-a-Service (SaaS), Platform-as-a-Service (PaaS) and Infrastructure-as-a-Service (IaaS).

In some of its materials, it actually refers to VIaaS (Virtual Infrastructure-as-a-Service). But a quick Web search shows VIaaS can actually stand for Video Intelligence-as-a-Service, and POCaaS could be confused with Payload Operations Concepts and Architecture Study (which, at least, isn't a service).

See why this has to stop?

Some people actually track this stuff, which is how I learned HaaS could stand for Hardware-as-a-Service or Humans-as-a-Service.

That last one just led me to coin Huh?-as-a-Service (H?aaS). I don't even want to see what Humans-as-a-Service entails. It makes me wonder about job security. I could be replaced by a Punch-Drunk Bloggist-as-a-Service (PDBaaS).

When there are so many service acronyms, how do you tell what stands for what? How do you know what MaaS means? It could be any of these: Malware/Manufacturing/Mashups/Media.

How about Madness-as-a-Service?

In addition to Software, SaaS could be Security or Storage.

How about Stupid-as-a-Service?

In addition to Infrastructure, IaaS could be Information/Integration/Identity.

How about Insanity-as-a-Service?

Enough of this. I'm starting to think about finding Beer-as-a-Service (BaaS) somewhere.

What's the dumbest "as-a-Service" acronym you've come across? Share here your thoughts, which will be put into our Disqus "Comments-as-a-Service" (CaaS) system for all to enjoy.

Posted by David Ramel on May 29, 20150 comments

Dev Survey Tracks Everything from Caffeine Consumption to Salaries

If you've got some heads-down coding on your plate, you'd best avoid the new Stack Overflow developer survey, for you might get bogged down in minutiae ranging from how many caffeinated beverages are consumed in various countries to indentation preferences to average salaries broken down by technology and other criteria.

"These results are not unbiased," Stack Overflow warned. "Like the results of any survey, they are skewed by selection bias, language bias, and probably a few other biases. So take this for what it is: the most comprehensive developer survey ever conducted. Or at least the only one that asks devs about tabs vs. spaces."

Stack Overflow, in case you didn't know, is the go-to place for coders to get help with their problems. The site reports some 32 million monthly visitors.

Using this unique status, the site polled 26,086 people from 157 countries in February, posing a list of 45 questions.

One of the key areas of inquiry concerned salaries, of course. The survey found knowledge of Objective-C paid off the best globally, with U.S. coders earning an average of $98,828, followed by Node.js., C#, C++ and SQL.

But if it's purchasing power you're interested in, Ukraine is tops -- at least according to the metric of how many Big Macs you can buy on your salary.

It also might help to work remotely, as coders who don't have to fight commute traffic earn about 40 percent more than those who never work from home.

On the technology front, Apple's young Swift language was the most loved, Salesforce the most dreaded, and Android the most wanted (devs who aren't developing with the tech but have indicated interest in doing so).

Interestingly, the popular Java programming language didn't make the top 10 list of most loved languages, or most dreaded, though it was in the middle of the pack for most wanted and came in at No. 3 in overall technology popularity.

Other survey highlights include:

• JavaScript is the most popular technology, followed by SQL, Java, C# and PHP.
• NotePad++ is the most popular text editor, followed by Sublime Text, Vim, Emacs and Atom.io.
• 1,900 respondents reported being mobile developers, with 44.6 percent working with Android, 33.4 percent working with iOS and 2.3 percent working with Windows Phone (and 19.8 percent not identifying with any of those).
• The biggest age group is 25-29, where 28.5 percent of respondents lie. Only 1.9 percent of respondents were over 50.
• Only 5.8 percent of respondents reported themselves as being female.
• Most developers (41.8 percent) reported being self-taught, with only 18.4 percent having earned a master's degree in computer science or a related field.
• Most respondents identified themselves as full-stack developers (6,800). Two reported being farmers.

And, oh, by the way, Norwegian developers consume the most caffeinated beverages per day (3.09), and tabs were the more popular indentation technique, preferred by 45 percent of respondents. Spaces were popular with 33.6 percent of respondents.

But there's more to that story.

"Upon closer examination of the data, a trend emerges: Developers increasingly prefer spaces as they gain experience," the survey stated. "Stack Overflow reputation correlates with a preference for spaces, too: users who have 10,000 rep or more prefer spaces to tabs at a ratio of 3 to 1."

I'm a spaces guy myself. How about you?

Posted by David Ramel on April 14, 20150 comments

Hadoop and Spark: Friends or Foes?

The first Spark Summit East conference concluded yesterday, just a month after Apache Spark practically stole the show at the Strata+Hadoop World conference, reinvigorating the debate about where the upstart technology fits in with the maturing Apache Hadoop ecosystem.

Certainly Spark is an improvement upon the original MapReduce component of said ecosystem, but there's a growing chorus of debate about whether Spark will mount a challenge to Hadoop itself, becoming its replacement and pre-eminent Big Data analytics tool.

Qubole Inc. works with both technologies and has a unique perspective on the debate. The Mountain View, Calif., company is known for its cloud-based Qubole Data Service (QDS), a self-managed Hadoop-as-a-Service (HaaS) offering.

Just last month, the company incorporated Spark into QDS, adding it to the bevy of Big Data components it works with such as MapReduce, Hive, Pig, Oozie, Sqoop, Presto and so on.

"There is a lot of excitement around Spark because it can give a real advantage in multi-pass iterative machine learning algorithms, as well as interactive data interrogation on in-memory data sets," Qubole CEO and Co-Founder Ashish Thusoo told ADTMag.com. "By many accounts it can tackle these workloads at speeds up to 100 times faster."

To review, MapReduce is the original massively scalable, parallel processing framework commonly used with Hadoop and other components such as the Hadoop Distributed File System (HDFS) and YARN. YARN can be described as a large-scale, distributed OS for Big Data implementations -- sometimes referred to as Yet Another Resource Negotiator -- which has been characterized as an improvement upon the MapReduce model.

As Hadoop has matured, the batch-oriented, disk-intensive MapReduce's limitations have become more apparent as Big Data analytics moves to more real-time, streaming processing and advanced implementations such as the aforementioned machine learning.

Spark evolved to address some of these shortcomings, becoming the most active project under the guise of the Apache Software Foundation (ASF) and most active open source Big Data project of any kind. It's commonly praised for its in-memory technology that boosts processing speeds up to hundreds of times over disk-based MapReduce computations in certain applications.

"Spark is a memory-centric data processing framework," explained Gartner Inc. Research Director Nick Heudecker to ADTMag.com. "It doesn't have a file system or a resource manager -- both things it has to get from another environment, like Hadoop or Mesos. Spark is typically faster than MapReduce for iterative processing. Another core difference is programming languages. MapReduce is written in Java, while Spark uses Scala. Scala is generally more fluent than Java, but Scala skills are harder to come by in the market."

"At the highest level, Spark is geared toward in-memory processing and Hadoop (MapReduce) is very disk-dependent," Thusoo explained. "This makes Spark particularly well suited for iterative algorithms that require multiple passes over in-memory data, while Hadoop's designed purpose is to manage very large volumes of data in a batch process workflow. Spark can work on top of Hadoop. They are different on many other levels, including technology maturity and language support."

That language support is also emphasized by Forrester Research Inc. as a strong Spark selling point.

"Spark includes APIs in Java, Scala, and Python that provide over 80 data transformation and action operators that hide the complexity of cluster computing," Forrester analyst Mike Gualtieri said in a report last month titled "Apache Spark Is Powerful and Promising." "Developers and data scientists can use the API and the supported programming language of their choice to develop any arbitrary data processing application, and the Spark engine will figure out how to execute the job efficiently on the cluster. In addition to the core APIs, Spark also includes specialized higher-level tools that can be used separately or together to build applications."

Also able to be used separately is Spark itself, with no required dependence upon Hadoop. "We are seeing a lot of applications in non-Hadoop environments, such as the public cloud," Databricks Inc. exec Kavitha Mariappan told ADTMag.com. Commercial Spark steward Databricks was founded by the original creators of Spark working at the UC Berkeley AMPLab.

Databricks -- with definite "skin in the game" in the form of its Spark-based "zero management" cloud platform -- expounded upon the benefits of Spark over Hadoop/MapReduce.

"The design of Hadoop MapReduce is over 10 years old, and MapReduce as a project is no longer rapidly evolving," Mariappan said. "Spark is fast subsuming it, and doing much more beyond what MapReduce ever could. In fact, many data processing jobs that were originally written in Hadoop MapReduce are being rewritten for Spark today."

While affirming that Spark will continue to play a big role in the Big Data arena, Mariappan stopped short of saying Spark will overtake Hadoop. "The goal of the Spark project is not to threaten or replace Hadoop, but rather integrate and interpolate well with a variety of systems (including Hadoop) to make it easier to build more powerful applications," she said.

Qubole, noting that it's "tool-agnostic," also isn't predicting that Spark will take over the Big Data world, either.

"We don't see that Spark has to win at the expense of MapReduce," Qubole's Thusoo told ADTMag.com. "For now, there are still distinct tradeoffs in terms of use cases, infrastructure cost and relative maturity."

Heudecker agreed. "It's easy to see Spark becoming the successor to MapReduce in the Hadoop ecosystem, but I'm not sure it's about picking one over the other," the Gartner analyst said. "While Spark is very early in its development, it represents the most substantial challenge to the incumbent Hadoop distributors. Recent benchmarks indicate Spark is substantially faster than MapReduce, using less hardware.

"Hadoop vendors count on selling more nodes and larger clusters," Heudecker continued. "Anything reducing the number of nodes required to perform the same tasks threatens not just numerous business models, but Hadoop's fundamental value proposition of being the primary, lower-cost alternative to traditional information infrastructure. Today, Spark is too immature to be considered a replacement for Hadoop, but it looks like the future."

Qubole, for its part, sees that Big Data future in the cloud.

"We actually take the position that there is a shortcoming in all these tools [MapReduce, Spark, Presto, Hive and so on], in the context of a larger business audience, and that is accessibility," Thusoo said. "The rate of failure with in-house corporate Hadoop projects is absolutely astounding. Besides poor scoping, as so much of this technology is new, a company really needs to assemble a unique, expensive and rare set of deep skills in both infrastructure building and programming before anyone ever gets to data science. This is what we set out to address in creating Qubole for Big Data in the cloud."

Heudecker also lended weight to the view that Hadoop hasn't fulfilled all of its much-hyped promises yet. "Thru 2018, 70 percent of Hadoop deployments will not meet cost savings & revenue generation objectives due to skills & integration challenges," he recently tweeted.

Echoing the view that Big Data as a concept is dying -- espoused by fellow Gartner analyst Donald Feinberg and others -- Heudecker denied that Spark is the future of Big Data.

"No. The future of Big Data is just data," Heudecker said. "It will likely take another five years, but Big Data is becoming the new normal. Spark may play a role, but it wasn't the first data processing framework and it won't be the last."

Posted by David Ramel on March 20, 20150 comments

Changing of the JavaScript Guard

Who would have foreseen the ongoing transformation of the lowly JavaScript Web scripting language to the go-to coding choice for native mobile apps and maybe even the desktop?

Coders from Facebook to Telerik are joining open source enthusiasts and traditional JavaScript-oriented vendors such as Appcelerator (Titanium) and Adobe (PhoneGap) to apply JavaScript in new and innovative ways for native mobile app development.

Along the way, they're breaking longstanding "best practice" rules for the 20-year-old language, stirring up the JavaScript community and forcing devs to reconsider how they structure and create JavaScript projects.

And from the reaction of some traditionalists, it promises to be a bumpy ride.

"First impressions were pretty skeptical," said Facebook's Tom Occhino in recalling his company's open sourcing of React.js, a new approach to JavaScript Web development, in 2013.

"Everybody kind of tuned out, they just shut off" when presented with a slide that showed a definite non-separation of concerns in some example code. "They were like, 'I don't know what that is; I've never seen that.' They took to Twitter. What they told us was that we'd taken a 'huge step backwards' in terms of the maintainability of our code, simply because we were embedding our markup, or our HTML, inside of our JavaScript. This was crazy. 'You can't do that!' " he recalled of the reaction.

Occhino was speaking in a keynote address at Facebook's React.js Conference 2015, wherein he introduced React Native, an upcoming approach that leverages an optional JavaScript variant called JSX to target iOS and Android apps. Instead of "write once, run anywhere" -- which is a "pipe dream," Occhino said -- it's "learn once, write anywhere."

"What is interesting is the language, JavaScript!" said one commenter on the ADTmag article about React Native. "Once thought of as a tool for purely Web design [it] has matured into a product worth considering coding applications in."

However, some developers were skeptical about React Native, too.

"So ... a JavaScript interface to a server that creates native views," read one comment on a Hacker News thread. "I don't get it, what is all the hype about? You've got an extra layer and level of abstraction (read: complexity) in your pipeline. I don't see how you can abstract away the idioms of a platform -- they're native. 'Write once, run everywhere' has failed time and time again. So marketing changed its tune to 'Learn once, run everywhere' and now people are gushing how HUGE this is?"

Others, however, expressed enthusiasm about the project and welcomed it -- even the established Appcelerator, which uses a somewhat different approach to coding native mobile apps with JavaScript.

"Welcome to the club!" said Appcelerator's Chris Bowley in a tongue-in-cheek blog post titled "Our Reaction to React Native (Or: Why JavaScript Will Rule the Mobile World)."

However, Bowley's main point was that Appcelerator has already been doing many of the React Native techniques. "There's always something to learn from other frameworks," he said. "But if there's one thing Appcelerator and we as community should learn is that it looks like we have to do a better job at getting the word out. The word that Appcelerator has been doing this for years!"

Well, not quite. The differences between the two approaches are varied and numerous and too extensive and technical to get into here, but obviously React Native is a much more limited offering -- used by many simply for the "view" part of the Model-View-Controller (MVC) architecture -- while the Appcelerator/Titanium ecosystem is much more extensive and complete. Not to mention React Native isn't a cross-platform approach and will be open source -- and thus free and not positioned for use with any other specific software.

In addition to Facebook, mobile dev tool specialist Telerik also recently debuted its own JavaScript approach to native mobile app development: NativeScript.

Now a subsidiary of Progress Software Corp., Telerik introduced NativeScript in a webinar last Friday. "This keynote changes everything we know about mobile app development," said program manager Ruslan Mursalzade in the webinar. Telerik is targeting NativeScript for native development of iOS, Android and Windows (Universal) apps.

The project uses a NativeScript Modules Layer to translate JavaScript calls to native APIs. "The JavaScript call doesn't get compiled, but instead it is interpreted at run time," a company spokesman said in a video. "There is no need for any wrappers to access native APIs, and as a result, there are no limits in terms of which native API functions your app can call. This is the foundation of the NativeScript framework."

And, of course, new projects that exhibit JavaScript's new direction are coming online regularly. For example, building on the React approach, the Reapp project was launched last month, already promising "a new way to build apps with React and JavaScript."

"React Native will be awesome," the Reapp project Web site states. "But you still need lots of work to make an app for all three platforms with it, and you'll need to know Objective-C and Java if you ever go outside of the React Native sandbox."

Reapp and other new approaches to JavaScript development leverage new capabilities in ECMAScript 6, the latest version of a JavaScript standardization effort undertaken by Ecma International, expected to be released midyear. (JavaScript is often referred to as an implementation of ECMAScript, much as ActionScript or Microsoft's JScript.)

"The Sixth Edition adds significant new syntax for writing complex applications, including classes and modules," the Wikipedia entry states. "Other new features include iterators and for/of loops, Python-style generators and generator expressions, arrow functions, binary data, collections (maps, sets and weak maps), and proxies (metaprogramming for virtual objects and wrappers)."

Yes, that's right: The lowly scripting language that was reportedly given its unfortunate name to capitalize on the '90s hype around Java is now getting more Java-like object-oriented programming (OOP) constructs. Already ubiquitous in the development world -- as evidenced by its consistently high rankings in programming language popularity indexes -- it's promising to become even more pervasive in projects everywhere.

It has long since migrated from client-side-only to the server with popular projects such as Node.js and many others. It's also gone from single-page application (SPA) approaches to "isomorphic" models where JavaScript apps can run on the client or server.

It also might even go to the desktop.

"How sane is it to do this for desktop apps?" asked an audience member during a "deep dive" into React Native in the January conference hosted by Facebook.

Right now, presenter Christopher Chedeau said, Facebook is concentrating on iOS and then Android. "But we're trying to think bigger," he said. "But it's a matter of resources." He speculated that maybe "one year down the road" some progress might be made in that area, or suggested volunteers could help spin up a Windows version or something comparable for the desktop.

However, it should be doable, Chedeau indicated, as there's nothing platform-specific in React. "If you can bridge components and APIs, you should be able to do it," he said.

So hang on -- the JavaScript bandwagon is going on an exciting ride!

Where do you see JavaScript going from here? Please share your thoughts in the comments section here or drop me a line.

Posted by David Ramel on March 11, 20150 comments

Academic Study: Don't Bother To Refactor Code for Quality

When I'm flailing about in code, I often quickly slap something together just to get it working and then go back to clean it up with simpler structures.

Real developers commonly refactor their code in this way to improve quality, readability, reusability and so on.

From Sri Lanka comes an academic report saying you probably shouldn't even bother -- if code quality is your primary concern.

The researchers defined refactoring as "the process of improving the design of existing code by changing its internal structure without affecting its external behavior, with the main aims of improving the quality of software product."

"This study [indicates] that refactoring does not improve the code quality," concluded Sandeepa Harshanganie Kannagara and Dr. W. M. Janaka I. Wijayanayake in a report published in January, titled "An Empirical Evaluation of Impact of Refactoring on Internal and External Measures of Code Quality."

One measurement, however, indicated an improvement in a metric called the "maintainability index," which logically follows since refactored code should be easier to analyze and understand by humans and thus be easier to maintain.

It's as if I "refactored" the study's title to change

"An Empirical Evaluation of Impact of Refactoring on Internal and External Measures of Code Quality"

to

"The Impact of Refactoring on Code Quality."

The new title is easier to read but doesn't improve much on the actual purpose of indicating the study's content.

The Sri Lankan researchers were trying to dig deeper into the nuts and bolts of the code to see if actual quality improvements could be proven. They noted that previous studies have concluded code refactoring improves quality, but most provided no quantitative evidence. "Although, the refactoring is by definition supposed to improve the maintainability of a software product, its effect on other quality aspects is unclear," the study said. "Therefore, there are hot and controversial issues in refactoring."

From where I sit, the study itself might be in for some hot and controversial commentary. It looks like there might be some concerns about sample size and quantitative analysis methodology. The researchers themselves admitted as much and called for further study on the subject.

"There are several arguments that may come against this study," they said, including the fact that more expert developers well versed in system design could serve as better evaluators of the code, even though the undergraduate students apparently used for analysis "have comparable assessment ability compared to a professional software developer." I personally have doubts about that -- there's no substitute for real-world experience.

So, basically, the study -- published in the International Journal of Software Engineering & Applications -- indicates the need for further study. "The results of this study indicate that there is further need of addressing the impact of refactoring," the researchers concluded. "Refactoring techniques used in this study were selected from the ranking done by previous study. Therefore, in the future it is better to conduct a study to find refactoring techniques which are commonly used in industry by a survey."

That makes sense to me. Developers and teams spend a lot of time on refactoring, and as this site's "Agile Architect" columnist Mark J. Balbes, Ph.D. said, it's instrumental to Agile practices and test-driven development. "If you are doing your work test-driven, then you also have the opportunity to think while you are writing the code," Balbes said. "The small refactorings you make along the way drive your system to a good design."

That's the common knowledge, but this study might give enterprise developers food for thought and perhaps incite them to study their own engineering practices. With release cadences quickening and dev cycles condensing, where should the devs expend their effort? If readability is improved but not code quality, is the time spent on refactoring worth it? What's the opportunity cost?

Posted by David Ramel on March 3, 20150 comments

Glimmer of Hope: Windows Phone Popular Among Hobbyist Devs and 'Explorers'

Being a hobbyist programmer, one of the things I found most interesting in a recent mobile dev survey is the high percentage of my ilk among Windows Phone developers, which perhaps provides a starting point for a resurgence of the struggling OS as Microsoft looks ahead to Windows 10 for a mobile rebirth.

"A massive 55 percent of Windows Phone-first developers are Hobbyists and Explorers," stated new research from VisionMobile Ltd. "All other developer segments are under-represented."

Hobbyists are "moonlighters building their own apps to learn and have fun," motivated by "fun, creativity and self-achievement." Explorers are "independent developers gaining experience as a side project to seize on future opportunities."

So I'm definitely a hobbyist. I've created working Windows Phone apps because I love Visual Studio. I've loved Microsoft tooling since I found out you could stop a program and inspect a variable -- in VisualJ++, of all things.

Unfortunately, Microsoft hasn't fared well in the mobile platform wars, and is rolling the dice on Universal Apps and Windows 10 to catch up to overwhelming market leaders iOS and Android.

And that's despite steadily growing developer mindshare and technology differentation, VisionMobile said.

"That Microsoft has so many developers prioritizing the platform at all is impressive," the study of more than 8,000 developers said. "It's a testament to the strong developer ecosystem they've built around their tools and technologies. Those tools are absolutely first class and many developers used to working with them are unwilling to leave them behind for less polished offerings. This makes Windows Phone an excellent starter platform for those with experience in desktop or server-side development looking to learn about mobile development."

While Windows Phone was dubbed "the platform for experimenters," the study pretty much reconfirmed the common view of Android as "the platform for everyone," iOS as "the platform for professionals" and mobile browser as "the platform for reach."

Tying Explorers for top billing at 23 percent of the surveyed universe were Hunters, described as "experienced developers building an app business and focused on the money." A far higher percentage of iOS developers are Hunters than any other group.

The Web guys had the highest percentage of Enterprise IT respondents, described as "CIOs and IT managers using apps to increase organization efficiency and reduce costs."

Along with experimenters, VisionMobile saw hope for Windows Phone among students who were taught with Microsoft tools. "These are also excellent candidates to get started with Windows Phone," it said. "Persuading developers already using other platforms to commit resources to Windows Phone is much harder."

Tackling that job is Kevin Gallo, who wrote a Windows blog last month claiming "Windows 10 is empowering developers to dream again."

"We are working to make Windows 10 a unified, developer platform for ALL of our devices so you can reach the greatest number of customers with your work across phones, tablets, PCs, Xbox, IoT devices and the new Surface Hub and HoloLens opportunities," Gallo said.

"We're also doing the work necessary to help make sure that apps and games look great across a full range of devices, display surfaces and input models," Gallo continued. "The Windows 10 platform will build upon the universal Windows app framework released with Windows 8.1 to provide developers the tools to deliver new app experiences across devices with a minimum amount of additional work."

Well, I, for one, want to stay with those "first-class" tools. I've never tried any iOS stuff and I haven't been too happy with my Eclipse and Android Studio experiences. So I'm glad Windows 10 will be a free upgrade and hope the underdog rolls a winner.

Posted by David Ramel on February 27, 20150 comments

The Last Gasp for Windows Phone

"iOS owns the premium segment, Android almost everything else, Windows and the browser fight for the scraps."

That's the conclusion of the latest comprehensive VisionMobile developer study, wherein more than 8,000 developers were surveyed about their OS targets of choice and myriad other details.

Despite a steadily growing developer mindshare and the differentiation of its technology, Windows Phone "is still not making any significant headway with device sales share, which is stuck at 3 percent," the study said. "Windows Phone is still fighting to build a sustainable niche but faces a vertical mountain climb before challenging the top two."

At about the same time, research firm IDC released data from its phone tracker project that pretty much reached the same conclusion.

"Windows Phone had the smallest year-over-year increase among the leading operating systems, growing just 4.2 percent, well below the overall market," IDC said.

"Instead of a battle for the third ecosystem after Android and iOS, 2014 instead yielded skirmishes, with Windows Phone edging out BlackBerry, Firefox, Sailfish and the rest, but without any of these platforms making the kind of gains needed to challenge the top two," said IDC's Melissa Chau.

Jackdaw Research devoted an entire study to Windows Phone a few months ago and ended up with an equally bleak conclusion.

"Windows Phone is growing modestly in terms of shipments, but not enough to gain share," Jackdaw researcher Jan Dawson said in the report. "Both iOS and Android are growing faster, and although Windows Phone is now clearly the third ecosystem in the smartphone market, it remains a very distant third, with no immediate prospect of catching up."

This must be incredibly frustrating for Microsoft, known for its focus on "developers, developers, developers ...." (Sorry -- I know that's the former CEO, but that video never gets old.)

Even though many developers have heaped praise upon Windows Phone, and with the release of version 8.1, reviewers such as Engadget said "it's clear Windows Phone has finally grown up," the OS can't make significant headway.

One of the main problems is kind of a catch-22 situation caused by the lack on inventory on the Windows Phone store compared to the "big two." Users are turned off by the poorer selection. Less marketing potential turns off developers, so fewer new apps are created, which further turns off consumers, and so on.

VisionMobile called this the "app-gap."

"Unfortunately, lack of scale means that the top new apps come to the Windows Phone platform quite slowly, if at all, and many others are not updated," VisionMobile said. "This leads to the vicious cycle of self-selection, also known as the app-gap -- most users who care about apps don't adopt Windows Phone and so in turn the platform isn't as interesting to the top developers."

Which leads us to Windows 10 and "Universal Apps."

"Microsoft needs more apps and more developer loyalty for its Windows platforms, especially those running on mobile devices," wrote longtime Microsoft expert Mary Jo Foley in her March column for sister publication Redmond magazine. "By making the underlying Windows Runtime, Windows Store, Windows APIs and tooling more common across the many Windows flavors, Microsoft is making the idea of building more Windows apps a lot more appealing, so the argument goes."

Microsoft is certainly pushing that argument. Kevin Gallo penned a Windows blog last month claiming "Windows 10 is empowering developers to dream again."

"We are working to make Windows 10 a unified, developer platform for ALL of our devices so you can reach the greatest number of customers with your work across phones, tablets, PCs, Xbox, IoT devices, and the new Surface Hub and HoloLens opportunities," Gallo said.

"We’re also doing the work necessary to help make sure that apps and games look great across a full range of devices, display surfaces and input models," Gallo continued. "The Windows 10 platform will build upon the universal Windows app framework released with Windows 8.1 to provide developers the tools to deliver new app experiences across devices with a minimum amount of additional work."

Foley isn't so sure. "I don't think it's a slam dunk that Universal Apps will help close Microsoft's current mobile app gap," she said. "Far from it. But that strategy remains Microsoft's Hail-Mary hope with Windows 10, at this point."

Hopefully, she said, Microsoft will address the unknowns about Universal Apps next month at its big Build 2015 conference.

Dawson pointed out three things Microsoft needed to do to catch up, including providing more help to app developers, especially after the initial deployment. "Unless Microsoft does these things, and does them well, it will not achieve mass-market traction for Windows Phone in the near future, and it risks spending a great deal of money developing an OS and creating devices, which never catch on in a meaningful way."

(Btw, to update, I love Visual Studio, never tried iOS and haven't much enjoyed my Android Studio experiences. I'm totally rooting for the underdog here.)

Posted by David Ramel on February 26, 20150 comments

Guess Who's Promoting Java for Cross-Platform Mobile?

I never thought I'd see this day: Microsoft is proposing Java as a cross-platform mobile development language.

For almost a month, Microsoft JUniversal tooling has been in public preview as the company seeks to smooth out the rough edges in its project to translate Java code into C#, with iOS translation on tap.

The irony is almost unbelievable, but I guess anything goes in this new age of openness, interoperability and inclusion. Let's all play together; we can figure out those pesky how-to-make-money details later.

Younger coders might not be familiar with the legendary Sun Microsystems vs. Microsoft wars of the late '90s and early '00s, stemming from Microsoft's own Java Virtual Machine used in Internet Explorer. Microsoft ended up having to pay a couple billion dollars in assorted fines and fees in its brouhaha with the then-owner of Java -- yes, that's right: "billions" with a "b." As the legal dust was settling, Microsoft came out with its own little project called the Microsoft .NET Framework using its new C# language.

Now Microsoft is saying: "OK, fire up Visual Studio and write some Java code to build a Windows/Windows Phone app." Well, kinda.

The JUniversal project was debuted late last month by Microsoft Open Technologies, the subsidiary formed to deal with, well, integrating open technologies into the Microsoft ecosystem and vice versa.

The goal is mobile dev nirvana: writing cross-platform code that provides native functionality, performance, and look-and-feel across Android, iOS and Windows/Windows Phone OSes. Dozens and dozens have tried, many have claimed success, but we're still waiting for the dream to be realized -- a true champion to be proven and crowned.

"Several options have been created to address this need, including Xamarin and Cordova," wrote Open Tech's Eric Mittelette in a blog post last month. I'd like to specifically mention JUniversal as another alternative, which allows you to write shared, cross-platform code in Java."

Note that this isn't proposed as that one elusive tool to do everything. It's aimed at parts of your codebase that can be shared easily, such as business logic. "As for the UI, the intention is that it's handwritten natively, to provide the best user experience," said Mittelette.

Which makes me wonder how this would work with the upcoming React Native project being developed by Facebook, a nascent JavaScript approach designed to be a new way of doing the UI view in the Model-View-Controller (MVC) scheme. Microsoft just announced a project to provide support for the React JSX flavor of JavaScript in the upcoming Visual Studio 2015, which knows a thing or two about MVC. Maybe JUniversal could provide part of the framework to use React Native components -- UI building blocks that can run on Android or iOS and provide full native functionality. Somebody please look into that and get back to me.

Meanwhile, Microsoft is asking mobile developers to look into JUniversal and get back to them.

"Want to try it out, as a pilot user?" asked project head Bret Johnson in a blog post last month. "Please do. Here's the deal: You'll likely run into some rough patches along the way, but in exchange for that you'll get one-on-one help from us, getting things working with your app. We need that feedback to improve things. So please both try it, via Getting Started, and reach out to us as you have questions and issues, so we can help you and fix up the doc/code for everyone thanks to your feedback."

The JUniversal project site goes into more detail. "The Java -> C# translator is basically feature complete," it says. "Expect some translation issues, but they almost always cause C# build errors, and the course of action then is to either tell us (so we can tweak the translator) or tweak your Java source code to avoid. Also expect some issues with incomplete doc, etc."

JUniversal was envisioned by some people from Nokia, acquired by Microsoft. In addition to the code translator, its other main component is JSimple, a set of libraries with APIs for non-UI stuff used across apps, such as authentication, JSON support, unit testing and so on.

"We're also looking for feedback on the JSimple API," says the project site. "Would you do anything different there in terms of API design, consistent naming, Java collection class enhancements, etc.? In some ways it's an opportunity to improve (at least modestly) on core Java APIs. If that excites you, input is welcome. Obviously, JSimple bug and feature requests are welcome, too."

So dive in, get your hands dirty and get back to Microsoft with your feedback. And get back to me on this JUniversal/React Native thing. Who knows? It could be the beginning of a beautiful friendship.

Posted by David Ramel on February 24, 20150 comments

Data Visualization Shows JavaScript Is Tops on GitHub

One of the coolest data visualizations I've seen in a while shows JavaScript rules the repository roost on GitHub, by a pretty big margin.

GitHut is "a small place to discover languages on GitHub," but it supplies a large amount of information, measuring active repositories, total pushes, pushes per repository, new forks per repository, opened issues per repository, new watchers per repository, the year the language appeared and much more. It hooks into the public GitHub API to grab data from the universe of some 3.4 million users and 16.7 million repositories on the GitHub Archive.

Hovering over an item in any of the columns brings up lines that show that item's ranking in every other column, with all kinds of data points showing up as you move around. Comments today on Hacker News refer to it as a "parallel lines chart" or "hammock chart" or perhaps even some new type of graph not yet named. The GitHut site says: "The visualization is based on two type of visualization, a Parallel Coordinates chart and a Small Multiples visualization."

Those visualizations help you instantly discover interesting information. For example, hovering over new darling language R (big in statistics and Big Data) shows it coming in as No. 12 in the Active Repositories ranking, but way down toward the bottom in Pushes Per Repository and yet No. 1 in New Forks Per Repository.

What does that mean?

It's hard to tell without some context, as several Hacker News commenters said. But it sure is fun to play around with.

One thing for sure, on GitHub, it's JavaScript, stupid.

It had 323,938 Active Repositories, compared to No. 2 Java at 222,852. Here's the top 10:

The info basically reflects that from several other programming language popularity indexes, where Java is usually right at or near the top. For example, it's now No. 1 on the PYPL PopularitY of Programming Language index for February 2015; No. 2 on the RedMonk Programming Language Rankings for January 2015; and No. 2 on the TIOBE Index for February 2015.

JavaScript, however, only cracks the top five on the RedMonk list, where it's No. 1 (though JavaScript was named "language of the year" for 2014 by the TIOBE index for its growth).

The GitHut tool also shows top active languages in a series of line charts with data from the second quarter of 2012 to the fourth quarter of 2014. Nothing much jumps out except for a dramatic downturn in the "view by percentage total" option for the Ruby language.

"This confirmed some of my suspicions," a Hacker News commenter said. "Ruby seems to be in decline, just like Perl, but not declared dead yet." But again, the data could be misleading without context. For example, one commenter noted that while percentage ranking declined for Ruby, the total number of repositories increased. That led to speculation that the percentage decline happened because Ruby was so popular with the original GitHub user base (the Rails community was a big early user) but its percentage of use has declined as more organizations joined the GitHub community.

So whether GitHut is "data porn" (flashy visualization with no analysis) as opined by one commenter or "an 'AHA' piece of statistics," in the view of another, the site is definitely worth checking out.

The actual usefulness is up for debate. "I feel this graph gives an idea of what the tendencies for a language is, and then you can research the context," one Hacker News commenter said. "You can glimpse a lot of fun things from this graph."

Here's the info straight from the GitHut site ("Carlo Zapponi 2014" is listed at the bottom):

GitHut is an attempt to visualize and explore the complexity of the universe of programming languages used across the repositories hosted on GitHub.

Programming languages are not simply the tool developers use to create programs or express algorithms but also instruments to code and decode creativity. By observing the history of languages we can enjoy the quest of human kind for a better way to solve problems, to facilitate collaboration between people and to reuse the effort of others.

GitHub is the largest code host in the world, with 3.4 million users. It's the place where the open-source development community offers access to most of its projects. By analyzing how languages are used in GitHub it is possible to understand the popularity of programming languages among developers and also to discover the unique characteristics of each language.

What did you get out of this data visualization? Know any others related to programming languages? Please comment here or drop me a line.

Posted by David Ramel on February 11, 20150 comments

What's Wrong at Debian?

What in the heck is going on over there in Linux-land? First, a prominent kernel developer reveals a movement to hire a "hit man" to deal with him, prompting him to pen an expose revealing that the open source community is "quite a sick place to be in."

Then a bunch of Unix "graybeards" threaten to fork the popular Debian distribution because of a dispute about a controversial kernel component, systemd, championed by that very same disgruntled developer, Lennart Poettering. A site was even launched to "boycott systemd."

Now longtime Debian programmer and influential contributor Joey Hess has announced he's quitting the project.

"It's become abundantly clear that this is no longer the project I originally joined in 1996," Hess wrote in a mailing list message last week. "We've made some good things, and I wish everyone well, but I'm out."

Hess didn't specifically mention the systemd brouhaha as a contributing factor in his decision to quit the Debian project, but rather blamed project leadership in general.

"If I have one regret from my 18 years in Debian, it's that when the Debian constitution was originally proposed, despite seeing it as dubious, I neglected to speak out against it. It's clear to me now that it's a toxic document, that has slowly but surely led Debian in very unhealthy directions."

Others, however, read between the lines and related Hess' decision to the systemd controversy. Several media articles, blogs and social media posts linked the Hess decision to systemd, as did at least one reader of the Hess resignation post. "I am highly concerned by the state of discussions in Debian triggered by the systemd integration -- I have never ever seen such a harsh, long and bitter discussion in Debian," replied the reader, one of many expressing sadness and regret at Hess' decision.

Systemd, as described by Wikipedia, "is a system management daemon designed for Linux and programmed exclusively for the Linux API. For systems using it, it is the first process that is executed in user space during the Linux startup process."

Poettering, the lead programmer of systemd, works for Red Hat Inc., a major Linux player whose Red Hat Enterprise Linux 7 beta distribution switched to using the systemd init approach in lieu of alternative technologies, such as sysvinit.

Less than one hour before his resignation note, Hess expressed frustration with a technical committee decision about handling a bug report related to the issue of requiring systemd in future Debian upgrades. Hess foreshadowed his decision to quit the project in his mailing list post titled, "please stop."

"This is not a decision-making process that will yield a high-quality distribution," Hess wrote. "Or one that I can be proud to be involved with. Or one that, frankly, gives me any confidence in the technical committee's current membership or indeed reason to continue to exist."

The details of this mess are murky, to say the least. On the mailing list, at least one developer apparently involved with the technical committee decision discounted Hess' interpretation of events, saying that his interpretation didn't reflect his actual intent. There's a lot of back-and-forth on the mailing list and in many other venues, and it's hard to figure out what's really going on.

Anyway, while Hess was beefing about leadership and procedure, others have had strident arguments about the systemd technology itself, along with the internal politics of how such project changes and developer/user options are governed. The use of the systemd component in Debian -- or at least the lack of a choice in using the technology -- caused the veteran Unix admins to threaten a fork of Debian, branching the project off into their own version.

"To paraphrase Eric S. Raymond on the issue, we see systemd being very prone to mission creep and bloat and likely to turn into a nasty hairball over the longer term," the protesters said on a new debianfork.org Web site with the heading, "Shall We Fork Debian?"

Since going up last month, the site has attracted hundreds of comments.

"Thank you so much for this," read one. "I've been using Debian since Hamm and this systemd nonsense has me ready to jump ship."

If that person does jump, he won't be the first ... or likely the last.

Posted by David Ramel on November 13, 20140 comments