Stack Overflow Data: React on the Rise, More Devs Self Taught, Rust Most Loved

Stack Overflow is out with the big daddy of all developer surveys, polling more than 56,000 coders around the world, who are increasingly self taught, embracing React in a big way and in love with the Rust programming language.

At least those are a few of the standout findings among survey results that are mostly the same as the previous year: JavaScript rules everything; Notepad++ is the most popular dev environment/text editor; Windows is the most popular desktop OS; and so on. This is at least the fourth year in a row that the popular developer-oriented Q&A site has published survey results culled from its millions of users.

What's strikingly new in this year's survey is the rise of React, the revolutionary Web tech introduced by Facebook that was last year modified for native mobile app development. While it's young and evolving on the native front, React is taking the Web dev world by storm.

React figured little if at all in last year's survey, but it's all over the new one. In fact, it was No. 1 among responses in the "Trending Tech on Stack Overflow" section, registering an astounding 311 percent increase, well above No. 2 Apache Spark at 164 percent. (Since I couldn't find any mention of it at all in last year's survey, I'm not sure where the 311 percent figure comes from). Note that I'm rounding off the percentages.

In the rankings of the top paying tech per occupation, React was tied for No. 1 among full-stack developers, with cloud and Redis, all pegged at $105,000. That salary put it in a tie for third place among "Top Paying Tech in U.S.," along with five other technologies.

"Newer Web-development technologies like React, Node.js and AngularJS are growing in use," the survey report noted.

It continued: "Full-stack developers who know JavaScript and develop for the cloud, or work with React or Redis are paid better than their peers. Front-end developers who know JavaScript and React, Node, or Angular get paid more than other front-end developers."

In the "Most Loved" category, React ranked No. 7. That question was one that saw a change from last year, with the Rust programming language taking over the No. 1 spot from last year's darling: Swift. Last year, Rust was No. 3, behind C++ 11. This year, F# took over third place behind No. 2 Swift.

Another notable change in results from last year concerned education, with far more respondents reporting being self taught, rather than having learned their craft through formal education. In the 2016 survey, 69 percent of respondents said they had taught themselves to some degree, a significant increase from last year's 42 percent.

"69 percent of all developers tell us they are at least partly self-taught. (13 percent of respondents across the globe tell us they are only self-taught.)," the report stated. "43 percent of developers have either a BA or BS in computer science or a related field. 2 percent of developers have a PhD."

(If nothing else, the survey taught me that some institutions of higher learning offer bachelor of arts degrees for computer science. Who knew? Are there bachelor of science degrees for fine arts?)

Other survey highlights include:

• The "Most Dreaded" technology (percent of developers who are developing with the language or tech but have not expressed interest in continuing to do so) was Visual Basic (80 percent), followed by WordPress (74 percent), and Matlab (73 percent). Last year, Salesforce was No. 1.
• The "Most Wanted" tech (not developing with the language or tech but have expressed interest in doing so) was Android (16 percent), followed by Node.js (15 percent) and AngularJS (13 percent). Android was also No. 1 last year.
• JavaScript was the most popular technology (55 percent). Just like last year. And the year before that. And the year before that. And probably next year. And the year after that.... That category was rounded out by the usual players: SQL, Java, C++, PHP and so on. Interestingly, while Objective-C has been No. 10 for the past three years, the young Swift language has yet to crack the top 10, despite receiving huge amounts of publicity and being open sourced by Apple last year.
• Notepad++ was the most popular text editor (35 percent), followed by Sublime Text (25 percent) and Vim (15 percent).
• The average developer respondent is 29.6 years old. The median is 27.
• The average developer has about 6.5 years IT or programming experience.
• Younger devs much prefer Star Wars over Star Trek. Older people (like me), much prefer Star Trek. Firefly is the top write-in, followed by Stargate, Doctor Who and Babylon 5.
• 93 percent of developers reported being male.
• The biggest loser in the "Trending Tech on Stack Overflow" (change in share of Stack Overflow votes) was, unsurprisingly, Windows Phone (65 percent), followed by Haskell (40 percent) and CoffeeScript (38 percent).
• The top paying tech worldwide (developer salaries as a percent of the average developer salary in a respondent's country) was F#, barely edging out Dart and Cassandra and Spark. In the U.S., the order is: Spark, Scala and Cassandra. (See more on Cassandra here).
• Top challenges at work include unrealistic expectations (35 percent), poor documentation (35 percent) and unspecific requirements (34 percent). That roughly correlates with other surveys like this one.
• For the first time, more developers are using Mac than Linux as their primary OS.
• Only 7 percent of developers identify as "rock stars."
• Most developers prefer dogs to cats. (But not developers in Germany.)

Unlike last year's survey, the 2016 edition contained no information about the amount of caffeinated beverages consumed or whether developers preferred tabs or spaces for source code indentation.

The survey was mainly based on 56,033 developers who answered questions on Stack Overflow, coming from 173 countries, who were asked 45 questions.

"Surveys aren't perfect," Stack Overflow said. "While our large sample size helps offset some biases, it's still biased against devs who don't speak English, or who don't like taking English-language surveys. In some sections we've augmented the results with insights gleaned from the activity of Stack Overflow's 40 million monthly visitors."

Stack Overflow also announced it has published a "2016 Developer Hiring Landscape" based on the survey data that's available for free download upon providing registration information. It's targeted at employers and recruiters looking to hire developers. According to that survey, "62 percent of developers don't currently have their dream jobs. Only 36 percent are currently in a job they love." Thus, the company says, "75 percent of developers are open to new job opportunities, even if they aren't actively looking right now."

Posted by David Ramel on March 17, 20160 comments

Share

• LinkedIn
• Facebook
• Twitter

Is Windows Phone Poised for a Comeback?

No way, right?

Conventional wisdom is that Windows Phone is dying a lingering death, caught in a vicious cycle of low dev interest -> less app inventory -> less consumer demand -> less monetization potential -> low dev interest ... and so on.

A VisionMobile survey last year summed it up: "iOS owns the premium segment, Android almost everything else, Windows and the browser fight for the scraps." I reported on that and other related data in a blog post titled "The Last Gasp for Windows Phone."

That conventional wisdom was buoyed by the actions of Microsoft itself, which has been bending over backwards to help developers build cross-platform and native iOS and Android apps with its mobile dev tooling in its new era of open interoperability.

And research firms such as IDC are continually issuing statistics like this:

And the list goes on. Everybody seems to have a knife in the back of Windows Phone.

Well, maybe I -- along with many others -- have been guilty of exaggerating the death of Windows Phone.

Consider:

• A new research report says Windows Phone developers earn more money on average than their iOS and Android counterparts.
• The New York Police Department is rolling out some 36,000 Windows Phone units to cops.
• New apps -- by some fairly big names -- are being rolled out.
• New phones -- by some fairly big names -- are being rolled out.
• People, and media, are talking more about Windows Phone recently.

What's going on here? Let's take a look.

The Survey
This is the "State of Mobile App Developers 2016" survey from InMobi, published a few weeks ago. Media outlets went nuts over its conclusion that "Windows Phone is the highest money-maker at $11.4k per month per app."

That's right: The Bangalore, India, company, specializing in mobile app advertising, claimed its research shows that -- on average -- Windows Phone devs make more than those targeting other platforms.

Even InMobi seemed to express some skepticism on that one.

"Since Windows has only a niche audience, the app store is not as fragmented as the Android and iOS counterparts," the survey report stated. "Hence app discoverability is way easier and the competition among apps is much lesser. Thus developers on the Windows App Store seem to enjoy the highest monthly revenue."

I added the emphasis to the word "seem." Since when does a conclusion based on research use the qualifier "seem?"

Over at betanews.com, readers had a field day savaging InMobi's conclusion, as could be expected. I, along with many others, dismissed the notion out of hand. Yet some readers went against the grain, saying it could be possible, despite numerous caveats. For example, many of the survey respondents were from the Asia-Pacific region, which might skew the total outlook. And the survey cited "average" -- or mode -- income instead of median, which could skew results. Also, Microsoft doesn't release store dev income stats like other stores do.

Nevertheless, some readers at least entertained the notion that it might be true, with comments such as: "Just thinking that it is possible" and "I don't find it hard to believe that developers on Windows can make some good money."

There's no way I can vouch for the accuracy of the data or conclusions based on it, so take it for what it's worth.

36,000 Cops Can't Be Wrong
It was revealed just yesterday that, following a pilot program, the NYPD is rolling out 36,000 specialized Windows Phone units to its officers.

As reported on NY1.com, and many others, more than 25,000 cops already have the phones, scheduled to be rolled out to the full force of 36,000 within weeks.

"The NYPD says its specially customized smartphones have been a major success in fighting crime," NY1 reported.

This is a big, highly publicized win for Microsoft. So, maybe there were some political factors involved in that decision -- maybe not. There's no way to prove that, so take it for what it's worth.

Hey Look, New Windows Phone Apps!
A betanews.com reader noted that "only this week, Game Troopers released two Universal apps (games), and recently King added Papa Pear Saga to Windows store. Just to cite two famous dev/publishers. Ah, yeah... And NASCAR w10 app was updated."

Other people are also talking about new Windows Phone apps. WinBeta.com recently published an article on its favorite Windows 10 Mobile apps, listing Cast, Readit, Tweetium and, yes, even Angry Birds.

You can see a lot more activity in the store and new apps on sites such as PreApps and on the Microsoft store itself. Of course, there are still recent headlines about big apps like Tumblr disappearing from the platform, and a steady stream of articles chronicling the death of Windows phone, so take it for what it's worth.

Hey Look, New Windows Phone Devices!
There are recent reviews of devices such as the Lumia 950, signifying the shift from Windows Phone to Windows 10 Mobile. You'll also see reviews of the Blu Win HD LTE and speculative reports of new Windows 10 Mobile devices in the works from HTC.

HP even got in on the act, recently unveiling a new phone, Elite x3, targeting the corporate market.

Paul Thurrott detailed a bunch of other Windows 10 devices announced at the recent Mobile World Congress, including the Alcatel Fierce XL, Panasonic Toughpad FZ-F1, Trinity Nuans NEO and other devices, including tablets.

Of course, publications like PC World noted that the Elite x3 "is a flagship sailing into a dangerous Windows phone wasteland," so take these announcements for what they're worth.

Some Buzz Is Back
The NYPD win was big news today, spawning headlines like "Windows Phone Isn’t Dead As All NYPD Police Officers Will Use It" and "Windows Phone Still Alive, 36K NYPD Police Officers Will Use It."

You can also read recent articles like:

• Windows Phone's next life: How Microsoft could recast it for productivity or services
• Windows Phone Is Not Dead: Slight Recovery in January After December Collapse
• Why Windows 10 Mobile could still be a sleeper hit

You can also read brand-new, in-depth analysis pieces like "What's the Deal with Microsoft's Mobile Strategy?" at our sister publication, Redmond Channel Partner.

Then again, you can also read articles like "Windows Phone Share Sinks to Just 1 Percent" in the same publication, so take all of these reports for what they're worth.

But hey, you're reading this, aren't you?

So for every point, there's a counterpoint. What's the real story? You tell me -- comment here or drop me a line.

Posted by David Ramel on March 1, 20160 comments

Share

• LinkedIn
• Facebook
• Twitter

Rise of the Developer Evangelist

Developers are a finicky breed apart. They brook no nonsense, suffer no subterfuge and rarely tolerate the non-technical. As they reject many traditional outreach methods from dev tool vendors, they require a new approach. Hence, the rise of the developer evangelist.

"Targeting developers with advertising is not effective," said Josh Marinacci. "It simply doesn't work." Marinacci is a developer evangelist at PubNub, which provides a data stream network API to help customers to connect, scale and manage real-time applications and Internet of Things (IoT) devices.

In light of his observation, you might have noticed developer evangelists are gaining more prominence in the industry, writing blogs, answering questions, coding demos, helping out at hackathons and doing hundreds of other things to spread the word among developers about their company's developer-related products and services.

To explore this expanding and evolving developer niche, I contacted Marinacci and a half-dozen or so of his peers to explore what developer evangelists do, their importance to the industry, their personality traits and what advice they have for coders looking to join the evangelical ranks.

Rob Spectre, a developer evangelist at cloud communications company Twilio, agrees with Marinacci about the special status of developers. "The currency of software developers is respect," he said. "Developers have an increasing influence in every business' enterprise, and if you waste their time with empty promises and marketing, they won't use your products -- and they'll tell their peers about the poor experience."

In fact, it's that failure to separate developer evangelism from marketing that provides one of the biggest challenges to Christian Heilmann, an active writer, presenter and well-known developer evangelist for Microsoft, focusing on the Edge browser. He literally "wrote the book" about developer evangelism.

"Companies tend to think of developer evangelism as a new way of marketing and people who used to do that can easily transition into that role by opening a GitHub account," Heilmann told ADTmag. "They can't. It is a technical role and your 'street cred' in the developer world is something you need to have earned before you can transition. The same way you keep getting compared to developers and measured by comparing how much code you've written."

How Often Do You Code?
In that last sentence, Heilmann was referring to challenges posed by the misunderstanding of the role. That misunderstanding can come from within one's own organization or from the developer target audience. "Developers keep asking you how much you code, assuming you betrayed the cause and run the danger of becoming yet another marketing shill," Heilmann said.

Journalists ask that question too, as I did. The wide range of answers I received speaks to the great diversity of the position.

"Not as much as I'd like," said Marinacci. "Probably 30 percent of the time, though much of that is really research. When a new technology comes out I'll investigate it and decide if it's something we should work with. When I do write pure code, say for a new demo, I end up writing it twice. Once to make sure the basic concept works, then again to produce concise and understandable code for other developers to read."

"As a manager, sadly not that much anymore," said Bear Douglas, developer advocacy manager at Twitter, who calls herself a developer advocate rather than a developer evangelist. "Before being a manager, it was probably 30 percent [of my] time, with the coding I was doing usually in service of trying out new APIs that were in development or creating code samples for docs and presentations. It varied a lot depending on if there was something specific I was working on."

"Once or twice a week I have to do some small amount of coding," said Kurt Collins, director of technology evangelism and partnerships at Built.io, which provides an "Integration-as-a-Service platform."

"Every day," said Twilio's Spectre. "Code is our primary vehicle for inspiring and equipping our peers."

"Every day," echoed Mark Headd, at Accela, which provides civic engagement solutions for government organizations. "If I'm not building a prototype app then I'm working through code provided by one of our developer partners that they might be having an issue with. I also help build some of our client libraries and SDKs. I particularly enjoy writing client libraries and have written several for our platform in different programming languages, as well as for other platforms that I use."

"As often as I can -- lately it's been more often which is great," said Kelly J. Andrews at Syncano, which provides a platform to build serverless apps (connected apps that don't rely on a back-end or server). "On average, I try to code a few hours a week, minimum, to stay in touch with that side of things. Week to week it can vary between 20 percent and 100 percent coding tasks. Just depends on what I'm working on at the time."

Day-to-Day Duties
What Andrews is working on at any certain time could be any of a zillion things, judging from my sample group, who were asked about their day-to-day duties.

"This role is anything but typical -- some days I'm coding, other days I'm recording a video, or I'm shipping boxes to an event," Andrews said. "We are a small organization, so we end up wearing many hats, but my days can include anything from development to documentation and anything in between."

Microsoft is the opposite of a small organization, of course, but Heilmann still has an equally diverse plate full of typical duties, such as:

• Helping product teams write and document good code examples.
• Find, filter, collate and re-distribute relevant news.
• Answer pull requests, triage issues and find new code to re-use and analyze.
• Help phrasing technical responses to problems with our products.
• Keep in contact with influencers and ensure that their requests get answered.
• Coach and mentor colleagues to become better communicators.
• Prepare articles, presentations and demos.
• Conference and travel planning.

"My day is usually spent supporting developers -- directly answering questions or requests for assistance in using our platform," said Headd, at Accela. "I spend a good deal of time building prototype or demo applications to show developers how our platform works and writing up examples for our developer blog. I also work internally with various teams -- marketing, engineering, documentation, etc. -- to make sure that the information and resources we have for developers are up to date and working well. I also travel quite a bit to conferences and events where I meet with developers and talk about our platform."

Twilio's Spectre said: "Developer evangelists inspire and equip their peers both online and offline. Online activities include coding open source projects, writing technical content and documentation and answering questions on Stack Overflow. Offline work includes helping fellow developers at hackathons, speaking at software development conferences and assisting tech meetup organizers in our developer communities."

"It's a lot of content creation -- writing docs, creating screencasts, sample code, presentations and so on -- and a substantial amount of partner and community support work," said Douglas. "At least one person from our team meets weekly with each engineering team for the platform to give them an update on customer issues and requests and share what we're hearing from people on the ground." She does a lot of work at events, which are prone to seasonality, so her duties vary by the time of year, with more of a focus on online outreach between events such as hackathons, meetups and conferences and -- lately -- the global #helloworld developer tour.

Collins, at Built.io, said: "I talk to a lot of people on a daily basis. Working with enterprise organizations and their representations requires a lot of conversation. In addition to that, I interface with our own development team a fair amount as I am essentially the voice of our partners. As such, I try to make sure our developers know what's going on in the minds of our partners and clients."

Over at PubNub, Marinacci said his schedule varies a lot from day to day. "Some days I'm prepping slides for to present at conferences," he said. "Other days I'm talking to customers about technical or business issues. Sometimes I work on our developer strategy for future products. Sometimes I code up cool new demos. Often I gather input from developers about our products and bring that knowledge back to engineering so that they can make our products and features even better."

Personality Traits
So there's a lot of communication involved with the job. Which doesn't fit in with the stereotypical image of an introverted developer. Which leads us to my next question posed to my group of "devangels," as Twilio refers to them: "What personality traits do you see as being important to being a successful developer evangelist?"

Collins picked up on the communication theme, implying that introversion might not matter that much. "You have to be able to communicate," he said. "I fully believe that inside each one of us is the capability to relate to everyone we meet. Being able to harness that power is key to being a successful developer evangelist. However, equally as important is the ability to analyze tough problems and creative solutions. The end goal of almost any interaction is to figure out a way to add value to both your own organization and the organization you're communicating with. Analysis is vital."

Andrews implied the introversion aspect may hold some developers back from evangelism. To be successful, he said, evangelists should exhibit "the ability to do more than code -- and more specifically talk to other developers in a personable way. I've met many developers who are absolutely incredible at coding, but aren't comfortable in a very public setting like speaking at a conference or talking to people at a meetup. The role is very much a mixture of marketing and development -- you have to be good at both to survive attending an event."

Douglas succinctly summed up her thoughts: "Enthusiasm, patience and sincerity."

"The job can be overwhelming -- especially when there are so many people who could use your help," she continued. "It's important to keep a close eye on your own burnout, particularly if you travel as well. Most of the people I know need breaks every now and again, but it's the genuine desire to help people and build great things for them that motivates us all through."

"Ultimately you need passion for something," answered Marinacci. "For me it was user experience. For others it might be compilers or databases or networks. If you have the passion, then you can pick up the speaking and writing skills."

Headd said becoming a devangel made him a better speaker and writer, as well as a better developer. "In my experience, developer evangelists are people that like helping others," he said. "They are people that are so excited about technology that they want to share what they have learned with others.

"Before I became a professional developer evangelist, I had been writing about different technology platforms for several years, and had already developed client libraries for several different APIs that I used regularly," continued the Accela devangel. "I was active in developer forums and enjoyed helping people work through problems with solutions they were developing. I liked creating open source software that I could share with others and was a frequent participant in app challenges and hackathons."

Communication was, again, the first thing that came to mind to Heilmann. "You need to be a good communicator," said the London-based Microsoft evangelist. "You need to not be arrogant and sure that you and only you can build great things but instead know how to inspire people to work with you and let them take the credit. You need to have a lot of patience and a thick skin.

"You will get a lot of attacks and you will have to work with misunderstandings and prejudices a lot of times," Heilmann continued. "And you need to be flexible. Things will not always go the way you want to, and you simply can not be publicly grumpy about this. Above all, it is important to be honest and kind. You can't get away with lies, and whilst bad-mouthing the competition will get you immediate results it will tarnish your reputation quickly and burn bridges."

Spectre didn't have much to say about introversion or personality traits, but did weigh in on the technical chops needed.

"Technical versatility is definitely more demanding now than it was five years ago," the Twilio devangel said. "Programming on the Internet continues to balloon in complexity: stylesheet preprocessors, transpiled languages like CoffeeScript and TypeScript, new languages like Go, Rust and Elixir and dramatic changes in client-side MVCs like Angular, Ember and React.

"The Web went from an already-complicated stack to an absurdly convoluted house of cards," Spectre continued. "And that is to say nothing of the vast complexity of mobile development with multiple languages, versions and toolchains for iOS and Android. It used to be a developer evangelist could get by on being conversant in a single Web scripting language -- those days are solidly in the rear view."

Reasons for the Rise
What isn't in the rear view is any notion that devangels aren't important to modern developer-related companies.

"Historically, this role has been a platform vendor role," IDC analyst Al Hilwa told ADTmag. "Typically, when a company creates a new platform, one that requires bringing developers up to speed to create an ecosystem of apps that run on the platform, then they create a developer evangelism team.

"The terminology goes way back to the birth of the PC when building applications outside of corporate mainframe systems started becoming a possibility," Hilwa continued. "Companies like Apple and Microsoft likely had the first such teams that were labeled 'Developer Evangelism.' From a skill-set perspective, these folks were effectively developers themselves and understood the vendor technology.

"The important point," the IDC analyst continued, "is that in this age of digital transformation where APIs to internal systems are exposed for mobile, IoT, Web or any kind of customer engagement access, the role is becoming much broader and many more companies are building such teams to attract developers and apps to their APIs."

The main benefit to those companies, Heilmann said, is developer retention and acquisition.

Headd picked up on the API theme mentioned by Hilwa. "If an enterprise has an externally available API, or is thinking about launching one, then they should consider how people will find out about it and learn to use it. Depending on how complex an API is -- or the functions that the API supports -- there may be a need to task specific people with assisting developers and providing support."

Spectre said that devangels connect with developers by meeting them in their own court. "Developer evangelism can fill the void created by traditional 'developer marketing' by respecting developers' time and effort," he said.

Marinacci put it more bluntly: "If you have developers as customers then you can't succeed without at least one developer evangelist on staff."

"Mindshare is probably the biggest thing companies hope to get out of it," Douglas said.

So You Want To Become a Developer Evangelist?
Finally, I asked the devangels what advice they have for devs interested in adding the title to their résumés. Here's what they said:

Andrews: "Do it. Be prepared for a wild, exhausting ride. Don't plan on doing it forever, but if you want to learn how to help others learn, and talk to a ton of people -- go for it."

Heilmann: "Start by documenting your work and writing about it. Then get up to speed on your presenting skills. You do that by repetition and by not being afraid of failure. We all hate public speaking, and it is important to get past that fear. Mingle, go to meetups and events and analyze talks and articles of others and see what works for you and is easy for you to repeat and reflect upon. Excitement is the most important part of the job. If you're not interested, you can't inspire others."

Headd: "Start writing and speaking about the technology you love, and showing others what you are doing with it. Being able to tell your story clearly and succinctly is an important trait of good developer evangelists. Some companies will feature developer stories on their sites and may even let you write a guest blog post about how you are using their platform. My first job as a developer evangelist came about largely because I was an active blogger and perceived expert on several different communication platforms," Headd continued. "There is no downside to being able to write and speak clearly about the technology that you are passionate about -- and it might even get you a job."

Spectre: "Focus on your technical skills. Aspiring developer evangelists need to be exceedingly b in their software development foundational knowledge, including algorithms, web and mobile platforms and data structures. Once your peers respect your technical abilities you can start writing tutorials for your favorite programming languages. Get involved in your local developer communities via tech meetups and when you're comfortable that you know a topic well, give a talk.

Collins: "Spend some time in your career being a software engineer. If you haven't been on the front lines doing code commits, then you're missing a huge part of the developer experience. That's a requirement when you're speaking to developers; having walked a mile in their shoes will help you get far."

Douglas: "Get involved in open source communities. All of them can use help in the core of what advocacy is all about -- helping other people be successful with the platform or framework. Write a blog post, host a meetup, contribute some docs -- it's a way to dip your toe in the water that also helps people out immediately."

Marinacci: "Write and speak about what you like to anyone who will listen. Learn from anyone who will teach you. Give a talk on something cool at a local meet up. Just go do it."

If you do just go do it -- and you live in San Francisco -- you might just be looking at a salary of $153,000, according to careers site Indeed.com, which pegs the average nationwide salary at $112,000. And there appear to be plenty of opportunities to break into the profession, with some 1,700 jobs listed on LinkedIn.com.

On the rise and there for the taking. Why not just do it?

What experiences have you had either being a developer evangelist or working with one? Comment here or drop me a line.

Posted by David Ramel on February 18, 20160 comments

Share

• LinkedIn
• Facebook
• Twitter

Left in a Lurch, Mobile Devs Scramble for Parse Replacements

Parse developer advocate Fosco Marotto was as surprised as everyone else when he arrived at work the morning of Jan. 28 only to discover that Facebook was killing the popular Mobile Back-end-as-a-Service (MBaaS).

He had intended that day to be the big launch of his pet Parse Server open source project, but had to change his rollout plans upon news that the Parse project would be closed down in a year, on Jan. 28, 2017. Instead of the news being all about the open source Parse Server, the news was all about Parse Server being just one part of one option -- out of many -- to help developers who now needed a replacement back-end for their mobile apps.

"Undeterred, I finished the launch procedures to open the code and publish the modules, and set out on social media to make sure developers knew about the open-source server and that it wasn't some migration tool," Marotto wrote in a post on Medium this morning about "Parse 2.0."

What it is, instead, is a "Parse-compatible API server module for Node/Express," or a way for developers to serve up the Parse API from any setup that can host Node.js apps, working with the Express Web application framework.

And what it is, suddenly, is a simple open source project with a whole new gravitas.

"Just one week after release, Parse Server has accumulated 4,700 stars, 900 forks, 200 issues, and 90 pull requests on GitHub," Marotto wrote. "A large community is forming, discussing feature implementations, adding new features, and helping each other diagnose and fix problems. Many infrastructure providers are getting involved, coming up with easier and easier ways to host the server for developers, and I expect we'll see at least one service pop up to host and manage Parse Server instances for developers who don't want to touch the back end."

Marotto told ADTmag that he will continue to work on the project, which he started at a weekend Facebook Hackathon.

"I'm going to continue working on the project, along with several other team members, to keep bringing new features to the product and help the community take over," he related to ADTmag in an e-mail.

He expects the open source project to soon become even more of a full-featured Parse replacement. "A short time from now, on the scale of a few weeks, parse-server will have all the missing features from the hosted solution," he told ADTmag. "Not long after that, it will be even more compelling to build on than ever."

When asked what's needed to realize that scenario, Marotto said: "The most pressing needs are the addition of Push Notification delivery and a Web-based dashboard. Both of these are already in-process, with pull requests being reviewed in the open already for Apple and Google push services. Within a few weeks, we should have both."

As far as his ultimate best-case vision for the project, he wouldn't provide specifics yet, but teased something that would provide a feel-good ending for the whole fiasco. "The actual best-case scenario, I don't think I can talk about ... but there is one in mind, and people will be very happy about it if it comes together."

Stay tuned for that one.

In the meantime, news sites, vendors and social media mavens everywhere were quick to propose alternative solutions for developers who need a replacement for their Parse back ends.

A Parse blog post last week touted "Hosting Your Own Parse on AWS and Heroku," using the Amazon Web Services cloud as an alternative solution.

Couchbase needed only one day to offer itself up for service, with an "I use Parse. They're shutting down. What should I do?" post.

On Twitter, tweets abounded about potential Parse replacements, with Apple's CloudKit, Microsoft Azure, Netmera and many more being proffered under the hashtag #parseshutdown.

New on GitHub is a Parse Alternatives project, listing dozens of options, ranging from AnyPresence to ZetaPush. That project categorizes the alternatives into general service providers, push notification providers, analytics providers, crash report providers, user administration providers, back-ends for game developers, Parse Server providers and more -- providing a hint as to just how full-featured Parse is.

However, others disagree with that notion.

"Whether intentional or not, it's actually a positive thing for devs," said one PR contact in an e-mail to ADTmag. "As a stand-alone MBaaS, Parse was handicapped by an inability to meet demands of great apps, which require outstanding user experiences and data integration that supports key business processes. Parse couldn't completely deliver on that." What can deliver on that, the contact said, is Appcelerator.

On Hacker News, commenters proposed alternative solutions ranging from ShepHertz to Hasura to Nimble Parse.

And, of course, Facebook, which acquired Parse a few years ago, offered up its database migration tool that helps shift data into a MongoDB database, along with a complete migration guide.

All of those proposed alternatives provide plenty of options for developers to get started revamping their Parse-based apps by the Jan. 28, 2017, kill date. Meanwhile, we can wait to see if Marotto's mysterious best-case scenario is realized. Either way, he seems optimistic about Parse Server's future.

"Parse is an amazing tool, accelerating mobile development with fantastic client frameworks," he said in his blog post today. "Now that the server is open-source, the Parse community is free to grow far beyond what was possible before, and you are invited to be a part of it."

What do you think Marotto's best-case scenario might be? What do you think of the whole situation? Did Facebook go about this in the right way? Please share your thoughts in the comments below or drop me a line.

Posted by David Ramel on February 8, 20160 comments

Share

• LinkedIn
• Facebook
• Twitter

5 Top Open Source Contributions for React Native (and What's Needed)

Less than a year after React Native was introduced as a new-age way to develop native iOS and Android mobile apps, the JavaScript-based technology has become one of the most popular open source projects on the GitHub code repository.

Since being open sourced by creator Facebook, React Native has garnered more than 26,000 "stars" on GitHub -- making it No. 23 in the all-time rankings -- and has been forked more than 4,600 times. Clearly, it's taking the mobile app dev arena by storm.

Even with all that, though, it's still an immature, evolving technology, just one tool among many needed for robust mobile development, rather than a complete end-to-end framework that can take care of all your soup-to-nuts mobile dev needs. In fact, its Web-based progenitor, React (or ReactJS or React.js), was intended solely as a JavaScript library for building Web site UIs, characterized by Facebook as the "V" (for View) in the MVC (Model-View-Controller) software architectural pattern.

React Native may well become a game-changer -- as I opined upon first learning about it early last year -- but it needs help. "Even though we've grown a lot in the past year, the team is only around 20 people," said Facebook engineer Christopher Chedeau -- a leader of the React Native project -- in a Reddit "Ask Me Anything" event last month. "This is ridiculously small given the amplitude of the project so we need to make some very hard prioritization decisions on a daily basis."

Help for those 20 people has come in the form of the open source community, hundreds of volunteers who are helping the core Facebook team add new features, improve functionality, fix bugs, flesh out documentation and more. As of press time, the React Native GitHub site lists 517 contributors, along with 4,893 commits, 22 branches and 49 releases.

Here, I'll take a look at some of the top React Native-related projects on GitHub, and follow those up with a list of areas where the Facebook core team would like to see more work done, according to the Reddit AMA.

React Native Desktop
Of course, just as soon as the Web-only React JavaScript library was brought to bear on mobile development, someone started thinking about transferring the technology to building desktop apps. That includes "Dima" (or "ptmt"), whose React Native Desktop project is designed to "build OS X desktop apps using React Native." (Like everything with React Native, Apple stuff takes precedence over Android here, also, much to my chagrin.)

Be warned, though, that "it's not production-ready yet." As the README.md file states, "Since it's simply a fork of React Native, basically you just can follow the same steps. Feel free to ask anything on #react-native-desktop channel if you run into problems (and you probably will)."

Despite that less-than-enthusiastic testament, the idea of targeting the desktop was one of the first questions asked in the Reddit AMA. When a reader questioned if Facebook had any plans to expand the React Native platform to desktop app development, a member of the core team (about 18 members participated in the Q&A exchange) replied: "I can't comment on Facebook's future plans, but I did see something on GitHub that seemed promising," and mentioned React Native Desktop.

"Thanks for mentioning it :)," said its creator, using the handle "potomushto" on Reddit. "Will see how everything will turn out, I'm trying to do my best building real product based on RN desktop."

Dima (or ptmt, or potomushto) is getting plenty of help himself on the project, which has 1,553 stars, 49 forks, 3,525 commits, two branches, one release and 343 contributors.

No doubt the project will attract even more interest as it moves forward, along with healthy doses of skepticism, like the following comment from "Jeckel" posted about a recent article discussing the "Changing of the JavaScript Guard."

JavaScript as a desktop programming language? I'll quit programming before I accept that as the right way to do things. Even with all the fanciness of ECMA 6, only an idiot would choose a non-typed script language over C#, C++ or even Java itself for desktop programs that actually have to accomplish work.

React Native Material Kit
This is one of multiple efforts with the aim of "Bringing Material Design to React Native." Developed by Yingxin Wu ("xinthink"), the GitHub site for the React Native Material Kit describes it as "a set of UI components, in the purpose of introducing Material Design to apps built with React Native, quickly and painlessly."

Material Design encompasses Google's app UI design principles, full of abstract design-speak concepts such as "material is the metaphor" and "motion provides meaning." Wikipedia says "Material Design makes more liberal use of grid-based layouts, responsive animations and transitions, padding, and depth effects such as lighting and shadows."

A GitHub Pages-generated site includes links to an NPM Module, the GitHub Repo and Annotated Source code for various UI elements such as buttons, cards, progress bars, spinners, sliders and so on. The project has 595 stars, 51 forks, 219 commits, two branches, 14 releases and 15 contributors.

xinthink said this project began by porting the MaterialKit, project, "But before long, I decided to rewrite all the components in JSX, with no or limited help of native code, and the rewriting is in progress. And lastly, it's the very beginning of the project, lots of work to be done, contributions are welcome!"

xinthink will be competing with similar projects for community contributions, such as MRN, "A Material Design style React Native component library," with an associated "Material React Native" demo app. MRN has 956 stars, 60 forks, 59 commits, three branches, zero releases and three contributors.

CodePush
Not only are individual contributors getting onboard the React Native bandwagon, some of the big boys are, too, like Microsoft, which developed CodePush to help deploy apps to devices.

"CodePush is a cloud service that enables Cordova and React Native developers to deploy mobile app updates directly to their users' devices," says an accompanying project site. "It works by acting as a central repository that developers can publish updates to (JS, HTML, CSS and images), and that apps can query for updates from (using provided client SDKs for Cordova and React Native). This allows you to have a more deterministic and direct engagement model with your userbase, when addressing bugs and/or adding small features that don't require you to re-build a binary and re-distribute it through the respective app stores."

The MIT-licensed project involves installing the CodePush command-line interface (CLI), creating an account, registering an app, adding the client SDK code (React Native or Cordova) to an app, and then pushing the code to all users running the app.

CodePush has 847 stars, 56 forks, 354 commits, 12 branches, five releases and 13 contributors.

React Native Package Manager
Inspired by Cocoapods, fastlane and react-native link, the React Native Package Manager "acts as your best friend and guides you through the native unknowns," says creator Alexey Kureev. "It aims to work with almost all packages available with no extra configuration required."

The project aims to help out with daily development chores such as automatic app store releases, over-the-air integration with AppHub and react-native-playground shares, the project site states.

"Why?" Kureev asks. "Tooling is important. We all know this. One of the biggest advantages of native iOS development is XCode and its great tools. Unfortunately, the process of adding native dependencies to React Native projects is far from perfect and our aim is to make it fun again."

React Native Package Manager automatically scans source directories and dependencies so it can link all appropriate elements without needing extra configuration, the site states.

"It detects Android package names, import paths, gradle location -- and for iOS -- it works with any code structure you have ever came up with. And don't worry -- in case it fails, you can always add rnpm object to your package.json -- our npm in a name is not a mistake! We embrace existing ecosystem and integrate with the present tooling for maximum developer experience."

The project has 504 stars, 12 forks, 404 commits, two branches, 12 releases and five contributors.

OpenGL Bindings for React Native
Based on gl-react, a similar project for the Web version of React, OpenGL Bindings for React Native was created "to implement complex effects over images and components, in the descriptive VDOM paradigm."

OpenGL "is the premier environment for developing portable, interactive 2D and 3D graphics applications," according to its site. It supplies a cross-platform API for rendering vector graphics. VDOM refers to the "(virtual) DOM" used in the Web version of React, a mechanism to speed up app performance by updating only components that have changed.

The gl-react project acts as a universal library with two implementations, one for gl-react-dom for the Web version of React (using WebGL) and gl-react-native for iOS and Android. According to its site, "gl-react allows you to write a fragment shader that covers a component. The shader can render: generated graphics/demos, effects on top of images, effects over content (video, canvas) ... anything you can imagine!"

The project has an accompanying examples project that demonstrates advanced effects using react-canvas, video effects, transitions, blurs, video blurs and other image effects for Web and native.

Created by Project September, the gl-react-native project has 526 stars, 25 forks, 224 commits, one branch, 43 releases and five contributors.

So What Else Is Needed?
While the aforementioned projects serve as a representative sampling of useful tools being developed to work with React Native, during the Reddit AMA, the admittedly small core team mentioned several areas where more community contributions would be most welcome.

React Native team member Felix Oghină indicated keeping up with community involvement was quite a chore in itself. "Triaging issues and pull requests takes precious engineering time away from us, and really the amount that we get has been overwhelming," he said. "But we have some initiatives here, for example, giving certain people in the community collaborator status so that they can close issues and merge pull requests. This has been super helpful so far, but we only started doing it very recently."

Christopher Chedeau (aka "Vjeux") also weighed in on the community response to the project. "We had no idea what the community really wanted," he said. "We got more than 10 issues a day a five pull requests and couldn't figure out what was important or not.

"For that we did two things," he continued. "The first is to setup Product Pains which let people vote on what the most important issues so that we can prioritize them the same way we prioritize feature requests from Facebook product teams. The second one is to bring in people from the community as part of the core team so that we have community people as stakeholders of the projects that can help drive the direction."

Following are some hints the team provided about where it might need help in driving that direction.

Windows
Targeting the top two mobile platforms -- iOS and Android -- leaves little time for the distant No. 3 in the arena, Windows or Universal Apps, but the notion was raised in the Reddit AMA, with one reader asking if such support is planned in the future.

"We'd certainly like to support more platforms in future, but right now we don't have any concrete plans beyond iOS and Android support," React Native team member Nick Lockwood replied, while colleague Konstantin Raev indicated that such a project might be tackled by the open source community. "We are working on a native bridge that will run on both Android and IOS," he said. "Community members expressed interest in supporting Windows and other platforms, that bridge may be useful to them."

In response to a question about Windows 10 support, colleague Spencer Ahrens replied, "RN for Windows can certainly be built and it would be cool if the community wanted to own that, but we have no plans internally."

Converting from Objective-C to Swift
"As a well established iOS dev, I would be way more inclined/interested in contributing to [React Native] if it were written in Swift," a reader said. "Is there any appetite for incorporating/eventually converting from ObjC -> Swift?"

Lockwood replied: "We have some limited support for writing React Native modules (plug-ins) in Swift already. We'd welcome pull requests that make that process simpler or more elegant." However, he said, that notion is complicated by two main problems: the Swift API is too unstable, with new releases introducing breaking changes; and the Swift runtime has to be embedded in every app because it doesn't ship with iOS, which significantly increases app size.

"For these reasons, we aren't using Swift in the Facebook app yet, and consequently we can't use it inside any libraries either (at least, not a non-optional dependency)," Lockwood said. "With that said, we are of course monitoring the progress of Swift with interest, and with the recent open sourcing, and hopefully stabilization of the API, we'll be looking to adopt it as soon as it's practical to do so."

Fixing ListView Memory Issues
Though one reader noted that "memory issues abound with the ListView," React Native team members indicated that the issue just isn't that high priority -- yet. "We have some new stuff in the works where this is a much bigger problem, and we're working on a solution," said Ahrens.

Chedeau also chimed in with another community call: "This is not a concern for the current use cases we have because we tend to only display a dozen or so elements. Most of the complaints about ListView are for hundreds-thousands of elements where it indeed doesn't work. We are prototyping many different solutions for the more general use case and would love for the community to do as well."

Choppy Navigator Performance
Answering a complaint about the poor performance of the Navigator component, team member Andy Street replied: "Performance has regressed over time and someone really just needs to profile it since it has run smoothly in the past. Unfortunately, I don't think that's on anyone's plate right now. We do have some docs on profiling Android performance here if you'd like to try to help out. RN is a huge effort and we're a small team and we really depend on the community to also help with the things they're using."

Porting to Game Engines
Q: "It's a stretch, but ... have you considered porting React Native to game engines such as Unity3d or Unreal? Last I checked, game UI was mostly 100 percent custom or involved very heavy frameworks that injected a full Webkit or Flash (scaleform) port."

A: "This is something that I personally really want," Chedeau said. "But, it's unlikely going to come from Facebook, we're not building anything with Unity3d or UnrealEngine so it wouldn't make sense to spend resources doing it. I hope that someone from the community is going to build that :) I already know several AAA games UIs that are built with React in a transparent WebView overlaid on top of the screen."

Apple iPad and Apple Watch Support
"It should work on iPad already but you will still have to write natively for Apple Watch," team member Brent Vatne said. "There aren't any plans to support it yet, but it's possible that someone in the community might step up similar to react-native-desktop that enables you to use React Native for OSX."

Android Parity and Going Forward
The top issue on the Product Pains site is "Get Android to feature parity with iOS," with 172 votes. That issue was also brought up in the Reddit AMA.

"I'm currently working on that," React Native team member Dave Miller said. "It's a moving target, but I am working through issues as they come up. I currently have a list of at least 50 items that I know of (some very specific, and others broad missing functionality) and I am sure there are more. That said, I think we will have major functionality equivalence over the next few months." He invited developers to post their specific issues on the Product Pains site.

As team members work on that and other issues to get React Native ready for production use in the enterprise, they provided a word of warning about the alignment of Facebook's priorities with the open source community.

Chedeau noted that "So far our framework was to prioritize what Facebook needed above all else. The reasoning behind this is that if we can't solve Facebook problems, no matter how much traction it receives externally, Facebook is going to stop throwing money at the project and it will be dead in six months."

A reader questioned that statement, saying it was a realistic fear for developers and asking if it should be.

Chedeau responded. "This is a legit fear to have and it is truly your decision to make," he said. "If you invest heavily in React Native you will have to bet on Facebook for the foreseeable future to make decisions that are favorable for your business, which is not its priority. Also one big point to mention is that React Native is still super early and there are a ton of things that are missing or buggy. So be prepared to have a bumpy road ahead. That said, the project is going really well internally. As you see here, Facebook is paying full time a lot of people to work on the project and quickly growing the team.

"I can't predict the future but it looks like this crazy experiment is going to work," Chedeau continued. "Even if it won't, it put developer experience and open source on the front stage of mobile development."

It surely did that.

Posted by David Ramel on January 27, 20160 comments

Share

• LinkedIn
• Facebook
• Twitter

Why Is Randomness So Hard in JavaScript?

So it turns out the random number generator long used by developers working with Google's V8 JavaScript engine doesn't really generate random numbers at all.

That's being fixed in the latest release of Google's Chrome browser (and the latest Firefox and Safari releases), but the whole issue begs the question: Why is generating a random number so hard?

Beats me. My brain starts to hurt the very second I begin to even think about understanding any math concept. And, I've discovered, a seemingly simple concept such as random number can be incredibly complicated. Perhaps nothing speaks to the mind-numbing complexity of computer programming like the vast amount of verbiage and math dedicated to making sure a blackjack player can't predict the next playing card to be flipped up.

Even talking about the problem is laden with complexity. People in this world use phrases like "external electromagnetic and quantum phenomena" and "natural entropy." And they don't say the random number generator function in JavaScript -- Math.random() -- is broken. They say it "offers sub-par quality."

Specifically, V8 used a pseudorandom number generator (PRNG) algorithm called MWC1616. The "psuedo" part comes from the fact that this doesn't even generate a true random number. Wikipedia says PRNGs produce "apparently random results" and the generated "seemingly random sequence" can be reproduced under certain circumstances. This is because the algorithm requires a seed value, or key, and if this is known, the seemingly random sequence can be reproduced.

The chances of that actually happening in the real world seem pretty remote to me, especially if the seed is the number of seconds elapsed since midnight on Jan. 1, 1980, or something. But some people care -- probably gambling sites and such where big money is at stake. For some cases, there are cryptographically secure algorithms available to generate true random numbers, but apparently at the expense of time or computing power. Everything is a tradeoff -- you can be wicked fast and less than perfect or you can be perfect and relatively slow, or prohibitively memory-expensive.

Anyway, Google software engineer Yang Guo last month pointed out that MWC1616 is flawed. Or rather: "MWC1616 uses little memory and is pretty fast to compute, but unfortunately offers sub-par quality."

Specifically, he said:

• The number of random values it can generate is limited to 2³² as opposed to the 2⁵² numbers between 0 and 1 that double precision floating point can represent.
• The more significant upper half of the result is almost entirely dependent on the value of state0. The period length would be at most 2³², but instead of few large permutation cycles, there are many short ones.
• With a badly chosen initial state, the cycle length could be less than 40 million.
• It fails many statistical tests in the TestU01 suite.

According to its site, "TestU01 is a software library, implemented in the ANSI C language, and offering a collection of utilities for the empirical statistical testing of uniform random number generators." I have no idea what the rest of his bullet points mean.

Regardless, Guo pointed out that the problem is being fixed by using a new algorithm called xorshift128+, which "uses 128 bits of internal state, has a period length of 2¹²⁸ - 1, and passes all tests from the TestU01 suite."

But, he warns, even that isn't cryptographically secure.

"For use cases such as hashing, signature generation, and encryption/decryption, ordinary PRNGs are unsuitable," the Google engineer said. "The Web Cryptography API introduces window.crypto.getRandomValues, a method that returns cryptographically secure random values, at a performance cost."

At any rate, the Math.random() function used V8 is being fixed in the Chrome 49 release, currently in Google's Dev Channel and scheduled for "stable" release during the week that ends March 8.

I still don't understand why true randomness is so hard to do without a big performance hit. It seems to me that literally every single thing that happens in nature (uninfluenced by humans) is random, so why should that be so hard to duplicate in computer programming?

I also don't understand, if the V8 problem has been known for years, why it hasn't been fixed before this.

I also don't understand if the problem even had any proven real-world significance. Did it really matter to anyone, even big Internet gambling sites where millions of dollars are at stake? Did anyone ever benefit by exploiting the flaw, or was pseudorandomness good enough, after all?

Then again, I've noticed I mysteriously continue to fail in picking winning lottery numbers. In fact, in the past few days, I've been unable to pick even one of the Powerball numbers on any of several $2 tickets I've bought in an attempt to win hundreds of millions (now nearing billions) of dollars. Hmm, I'd better check on what algorithm the "pick-six" lottery uses. Maybe it's time to use a manual card and start filling in those little ellipses with a pen. That should pass everything in the TestU01 suite.

So what's the deal with randomness? Does it really matter? Comment here or drop me a line.

Posted by David Ramel on January 13, 20160 comments

Share

• LinkedIn
• Facebook
• Twitter

3 Trends Shaping Mobile Development in 2016

Last year saw the emergence of forces promising a tectonic shake-up of the mobile app development industry in 2016. Following are three trends mobile developers should keep an eye on as we progress in the new year.

New-Wave JavaScript
Part of the larger story of JavaScript evolving into a first-class programming language option far beyond its Web site scripting origins, this trend was exemplified by the emergence of React Native in the mobile realm. Facebook engineers took their React framework for building Web sites and applied it to creating fully native mobile apps for iOS and Android.

What sets React Native apart from a zillion other JavaScript frameworks/libraries is its unique approach to cross-platform app development, eschewing the classic "write once, run anywhere" approach in favor of a "learn once, write anywhere" paradigm. As explained by Facebook engineer Tom Occhino, company devs decided that "write once, run anywhere" just doesn't work, despite myriad attempts to realize the dream of using one codebase to target multiple OSes. No matter what, he said, the resulting apps derived from the traditional cross-platform approach never quite match the performance of "real" native apps developed specifically for one OS using requisite native languages and tools.

Occhino highlighted various attempts to duplicate native widgets as an example. "Native widgets are a black box," Occhino said during a conference keynote address in January when the company announced React Native. "We don't have access to the source code. We can't see what the parameters are." Developers just can't see the numbers, the specifications, the things that make widgets "feel like they feel," he said.

"And any time somebody tries to reimplement a native widget using HTML, CSS and JavaScript, it always feels like s__t," Occhino said. "You can get close ... you can kind of make something that's ... yeah, it's almost indistinguishable ... it's not even close!"

Instead, the Facebook way requires dev teams to learn React and then apply that approach to say, coding an iOS app in one separate project and then immediately creating a similar app for Android using the same technology, which the company claims will speed up development cycles.

The React approach itself is radically different from traditional coding methodologies, completely rejecting some time-honored coding conventions like the separation of concerns such as UI markup and logic. As noted on the official React for Web site, React uses its own JSX syntax extension for component-based coding in JavaScript, along with a "virtual DOM" that helps specify what parts of a UI need updating. This "diffing" approach is carried over to native development (without the DOM aspect) so just certain UI components are updated when their data-based "state" is changed.

While the React Native ecosystem is evolving and maturing, it still closely fits the original React philosophy of just supplying the view in the Model-View-Controller (MVC) approach. This year will see the fleshing out of ancillary components that make up a more complete dev system that provides back-end functionality such as working with databases. These include Relay, a JavaScript framework for creating data-driven React applications, and GraphQL, a query language for describing the data models used in client-server applications.

These maturations will position React Native for even greater use in 2016, building on the accolades the technology garnered in 2015. One of those came from influential Mozilla developer James Long. "This is solid engineering," said Long in detailing his first impressions of trying out an early version of React Native. "And it completely reinforces the fact that React.js is the right way to build apps. I can write a native app using the same techniques as I would write Web app."

And React Native isn't the only new-wave JavaScript approach we'll see in 2016, as other industry players including Telerik have come out with their own alternative techniques, such as Telerik's NativeScript.

Progressive Web
While the Web vs. native app pendulum has been swinging back and forth for some time, new developments in 2015 saw cutting-edge technology and techniques being brought to bear in the Web arena that might tilt developer mindshare away from the strictly native approach.

A prominent champion of many of these techniques and technologies is Google, which places them under the umbrella of the Progressive Web. "A Progressive Web App uses modern Web capabilities to deliver an app-like user experience," Google says on its Progressive Web explainer. "They evolve from pages in browser tabs to immersive, top-level apps, leveraging the Web's low friction."

Chrome developer Alex Russell expounded on the idea in a June blog post. He described the new class of Progressive Web apps as being responsive, able to fit any form factor; connectivity independent, being progressively enhanced with Service Workers to let them work offline; discoverable, being identifiable as "applications" via W3C Manifests and Service Workers; re-engageable through the use of push notifications; and installable as homescreen apps on a device. Other attributes included being able to support app-like interactions, being safe, being always fresh with updated information and being linkable or "zero-friction, zero-install, and easy to share."

An example of this new-age approach is the Web app developed by Indian e-commerce retailer Flipkart, which uses the Progressive Web techniques and technologies in a new Web app that handles problems such as lack of network connectivity.

Another company taking the progressive approach is longform journalism publisher The Atavist, which gave up on native mobile apps for its site in favor of a progressive approach.

As standards such as Service Workers mature and are adopted in greater numbers, 2016 will see a coalescing of the Progressive Web approach. At least Google is hoping so. "Progressive Web Apps are experiences that combine the best of the Web and the best of apps," Google said. "They are useful to users from the very first visit in a browser tab, no install required. As the user progressively builds a relationship with the app over time, it becomes more and more powerful. It loads quickly, even on flaky networks, sends relevant push notifications, has an icon on the homescreen and loads as top-level, full screen experience."

Citizen Developers
With the cursed shortage of skilled mobile dev talent persisting, more "citizen developer" initiatives took root in 2015 to feed the gaping maw of enterprise mobile app development. Whether they're called "low code" or "no code" approaches, or rapid application development (RAD), or "do it yourself" (DIY) or WYSIWYG or whatever, a plethora of tooling emerged last year to take mobile app development beyond the bailiwick of trained professional developers and put it into the hands of ordinary business users.

Typically such solutions rely on drag-and-drop functionality, project templates, WYSIWYG design, prebuilt components, automated services and more to place programming within the grasp of non-developers.

Although it has been discussed for years, the citizen developer movement evolved last year to the point that Intuit QuickBase published a study of the phenomenon, titled the "State of Citizen Development Report. It revealed "a new class of application developers" who weren't coding experts gaining more efficiency and speed, but rather less-skilled enterprise staffers teaming up with IT pros to crank out apps faster.

"There is a paradigm shift now occurring in modern application development from early adopters embracing low code platforms for Citizen Development," Intuit QuickBase said. "These organizations are driving digital transformation throughout their organizations by embracing no code Citizen Developers that help reduce the time to market for new applications and ongoing customizations, increase the ROI of app dev projects, and perhaps most importantly, drive operational efficiencies by solving challenging business problems in the last mile of the application."

The number of citizen developer offerings increased greatly last year with many improved and brand-new products hitting the market. Just some of those covered by ADTmag included:

• WaveMaker Inc. announced that its mobile rapid application development (MRAD) tool now lets developers create hybrid apps along with pure Web apps.
• Microsoft introduced PowerApps, the company's new low-code cross-platform mobile app development solution designed to let non-developers create enterprise apps.
• Kony Inc. and Exicon Ltd. announced a partnership to provide a simplified "plug-and-play" solution for enterprise mobile development efforts, where customer engagement counts more than the number of app downloads.
• Mendix said it addressed the thorny problem of handling offline functionality in mobile apps with the latest rendition of its RAD tool.
• Gupta Technologies announced its TD Mobile tool for simplified enterprise app development has added capabilities to create hybrid cross-platform mobile apps.
• Telerik announced the addition of low-code features to its mobile development platform to let non-programmers help satisfy the exploding demand for enterprise mobile apps.
• IBM entered the low code sweepstakes via a partnership with Ionic that combines the drag-and-drop design capabilities of Ionic Creator with IBM's MobileFirst Platform.
• RAD specialist Appery LLC announced it has integrated the Ionic SDK into its cross-platform development framework, targeting coders building hybrid mobile apps with Web technologies.
• Project Eve attempted to turn the whole citizen developer notion around, approaching programming from a new direction that emphasizes analyzing and communicating information rather than building applications.

In fact, the explosion of simplified tooling prompted research/review firm Clutch to publish a ranking of different solutions, with the top tools listed as Como, ShoutEm, Bizness Apps, Appsmakerstore, GoodBarber, Appy Pie, GameSalad, Snappii, Apptive, Yapp, AppInstitute and Verivo's AppStudio.

With the skills shortage showing no signs of letting up, these and other solutions will continue to evolve in 2016, letting more people in on the enterprise app "gold rush."

So whether you're a JavaScript jock, business analyst looking to do some coding or a Web developer looking for new opportunities, 2016 is promising to be a very interesting year.

What other trends do you see coming up this year in the mobile app development space? Comment here or drop me a line.

Posted by David Ramel on January 4, 20160 comments

Share

• LinkedIn
• Facebook
• Twitter

Speedier Android Emulator Preview Now Available (Hallelujah!)

Well, my holiday present arrived early: The promised preview of a speedier Android emulator is now available.

While the Android Studio 2.0 preview was made available in November, the emulator part was delayed until yesterday's release of Android Studio 2.0 Preview 3.

It's about time. There's just no way to quantify or qualify the immense frustration suffered by thousands of Android developers who have been forced to use the slowest software ever conceived: the emulator running on Windows.

Complaints on coding sites like StackOverflow abound, with one classic question ("Why is the Android emulator so slow? How can we speed up the Android emulator?") receiving 2,088 votes (that's a LOT). A theme common to many of these questions is just plain dumbfoundedness on how long the emulator takes to even load, much less do something. It's like: "I've been waiting [20, 30, ?] minutes now. How do I tell if it's working?"

I've been there. Numerous times I've thought: "Well, it must be frozen, better try again." Only to exit out and try again, maybe close the IDE and restart, maybe even shut down the PC and restart -- only to see the same thing happen again, prompting staggering disbelief at the time and effort needed just to see how that latest tiny tweak on the UI is working out.

Well, supposedly (I haven't had time to check it out personally yet), salvation is at hand, according to a blog post published yesterday by product manager Jamal Eason.

"When emulating the latest Android 6.0 release (Marshmallow), we now support Symmetric Multi-Processing (SMP) and have made significant I/O improvements in both the emulator and ADB. This means you will have faster performance when you are testing your app."

Wow. I'm not even going to question how multi-processor support is just now being introduced (haven't multi-processor, multi-core smartphones been around for a while now?). I'm just thankful. (To be fair, there a lot of thorny technical issues involved with SMP on Android that you can learn about here.) I simply concur with the thoughts of Trevor Mack, who said in a Google+ post yesterday: "Android Studio 2.0 Preview 3 includes new Emulator announced that we all have been anxiously waiting for."

Eason detailed performance improvements for both CPUs and the Android Debug Bridge (ADB) that communicates with emulator instances.

"Android Studio now uses CPU acceleration on x86 emulator system images by default," he said. "Combined with new Symmetric Multi-Processor (SMP) support in Android 6.0 Marshmallow system images, the Android emulators can perform even faster than many physical Android devices. Multi-core support not only makes your apps and the emulator run faster but it provides the added advantage of speeding up common developer tasks such as installing APKs. Also, with SMP you can test apps that specifically target multi-processor Android devices."

Regarding the ADB, Eason said under-the-hood improvements now let developers push files across the bridge up to 5x faster than a physical device.

The emulator UI has also been upgraded, Eason said, with a new toolbar and control panel to augment command-line options; window zooming and scaling; drag-and-drop functionality for installing APK files or moving any files to the emulator's SD card storage; and extended UI controls for testing functionality such as phone calls, sending SMS messages, using GPS and more;

Eason said the team will continue to add functionality and features.

"This is just the beginning of developments on the Android Emulator, so expect more features such as support more APIs levels, and adding more sensors with future versions of Android Studio," he said. "The new emulator along with Android Studio are available today on the Android Studio canary channel and tools preview channel."

If you're interested, the Android dev team has published instructions about how to set up the emulator preview.

So go forth, emulate and enjoy. No more firing up the emulator to see how that new menu works and going out to finish that addition to your house while you wait.

Posted by David Ramel on December 11, 20150 comments

Share

• LinkedIn
• Facebook
• Twitter

Being Thankful for Open Source (But Why Do Companies Do It?)

It's Thanksgiving time, and I'm surely thankful for the free open source software I use. But going open source always seemed counter-intuitive to me. Why would a company invest time, money and development resources to create valuable intellectual property and then throw it out to everyone to use for free as they see fit?

Especially if they see fit to use your open source software against you in competitive products. That's reportedly what happened with mobile dev company RoboVM.

"We have seen competitors actively exploiting our good faith by using our open source code to compete with us directly in commercial products," read a recent Google Groups post from RoboVM exec Mario Zechner about the company's decision to end its open source efforts.

Henric Müller, CEO, wrote his own post on the matter. "We have received no notable external contributions to the components that represent the core of our product," he wrote, which "means that neither RoboVM customers nor us, as the maintainers of RoboVM, have realized any benefits to sharing the products source under such liberal terms." (You can read more details here.)

Which got me to thinking. Why isn't this happening to more companies? You always hear about the many benefits of open source, but exactly how are companies benefitting from creating products for free?

User and Developer Benefits Are Clear
It's much easier to understand from the users' and developers' point of view. For users, it's: Hello, free software! For developers, they get experience, perhaps exposure and even notoriety and fame (hey, it worked for Linus), improved marketability and surely just "feel good" satisfaction in contributing to the greater good and seeing their creations publicized and put to use.

Some researchers recently tackled the question, publishing an official academic study examining the "Motivation, values, and work design as drivers of participation in the R open source project for statistical computing." But it's full of research-ese nonsense like "The data are analyzed using item response models and subsequent generalized linear models, showing that the most important determinants for participation are a hybrid form of motivation and the social characteristics of the work design. Other factors are found to have less impact or influence only specific aspects of participation."

I don't know what that means and I'm not paying for the report to try to find out. Why can't they talk in plain English? Why can't they open source their research?

On Quora, where they talk in plain English, a question asked "How rewarding is open source for a programmer's career?" One answer included this: "The reason I 'open source' my code, or at least talk about it at length, is -- I find it rewarding that I am lessening the suffering of other developers and that others may go on to discover new things thanks to work I have done." Another answer said: "Many of us program for the sheer love of programming. The money is just gravy."

Microsoft's Big-Time Turnaround
Well, the gravy is essential to for-profit companies -- it kind of keeps them going. They're not so much into "feel good" satisfaction, leaning more toward a bottom-line profit. How does open source contribute to that? Take Microsoft, the poster child for doing an about-face turnaround on the issue. After years of being the bastion of proprietary software, they've gone nuts, open sourcing everything from its .NET Framework to Visual Studio itself. Where will it end, with Windows?

How is that helping the company? I can see the obvious things: community goodwill, greater exposure and branding, loss leaders for profitable products and so on. But how much does that help the bottom line, and how do you even measure any financial impact?

Open source champion journalist Steven J. Vaughan-Nichols shed some light on the matter in a recent Redmond Magazine cover story, "How Open Source Is Shaping Microsoft's Future." He quoted Allison Randl, president of the Open Source Initiative, as saying companies need to go open source or get left behind in the software development game.

"Microsoft knows this and is aware it can no longer take a 'not invented here' attitude any more," Vaughan-Nichols wrote. "Microsoft's new management realizes the old proprietary software business model that served it well for so many decades has been milked as much as it can be. Hence, Microsoft has been moving to a service-oriented business model and, at the same time, the company is moving to open source software to power those services."

I don't know. It all sounds good, but I still don't see a clear profit motive. So I went looking for more answers.

An Open Source Expert Chimes In
I started off asking Mr. Open Source himself, Steven Vaughan-Nichols, mentioning the RoboVM case.

"Today, the question isn't 'Why open source?' he replied in an e-mail. "It's 'Why would you not open source your software?' The more eyes you get, the more help you can find, the greater your project's development resources. Today the only major software company that hasn't bowed to this categorical imperative is Apple. ​As for RoboVM, I don't know the details, but I strongly suspect their problem boiled down to 'They were doing it wrong.'"

I asked Vaughan-Nichols about the "using-it-against-us" reasoning of RoboVM in explaining why they quit open source. "Companies in the open source space, including even [Microsoft] these days, have to change their business plan focus," he replied. "The shorthand I use to explain this shift is that you're no longer trying so much to get a bigger slice of a pie, you're trying to expand the size of the pie.

"So, they should be using their open-source code in their own commercial products," Vaughan-Nichols continued. "They should be spending their marketing dollars on explaining why their commercial adaptation is better than their competition's, expanding their support services. If someone is actually ripping off their code and putting it into a proprietary product, it's time to turn to the lawyers. Depending on the license they're using, there's almost always a way to throw water on someone who's simply stealing code."

What the Web Says
There are many more opinions on the Web, of course.

An article on readwrite.com offered "5 Reasons Your Company Should Open Source More Code," boiling down to: great advertising; a force multiplier (if others work on your project); attract talent; best technical interview possible for companies that are hiring; retaining talent.

Another Quora question asked "How would companies make money if all software was open source?" One answer read:

• Ads: Twitter, is built using open source code. Also signing up for it is free. In spite of that, it is valued at $18bn+. And 85 percent of its revenue comes from advertisements.
• Hardware: Android, one of the most widely used mobile operating system is open source. But Android also needs hardware to run on. Individual hardware making companies mod android according to their needs (and also pack in a few proprietary software sometimes) and ship their devices.
• Services: Netflix is open source too. But it does charge a sum of money for its services. Also Wordpress, being open source, charges for domain names and hosting spaces.
• Value added contents: While open source codes are free to download and use, it is also possible to charge for premium content. Like Wordpress gives you a set of themes to work with, but it gives you the option to buy themes too!

Divio recently explained "Why we support open-source software." "It's not always clear to people why companies like Divio -- businesses that need to make a profit -- would want to give money away to open-source communities and projects," the article states. "Giving money away, after all, is not the first thing one would put on a business plan."

Part of the reason Divio does it is community goodwill, along with return on investment that might not be immediate and might not be obvious, like long-term community investments. "The fact that many companies -- successful, profitable, sensible ones, like Divio -- do make those long-term investments in the community is an indication that this is a wise way for them to spend their money," the article states.

Wired recently wrote that "Open Source Is Going Even More Open -- Because It Has To." "Why are so many companies giving away their intellectual property?" the article asks. "It's not happening for altruistic reasons."

Rather, Wired said in discussion about Google's decision to give away rights to the Kubernetes cloud computing system, "Companies like Google want others to use their open source software since it can help drive the use of online services, like Google's cloud computing tools. They want others to contribute code to this software too. But increasingly, others don't want to use or contribute to projects unless they're independently managed."

So you get the idea. A lot of "soft" reasoning, but not much hard data on how open sourcing your software contributes to the bottom line.

Nah, It Can't Work
And there are some naysayers. CIO recently explained "Why the open source business model is a failure." "Open source software companies must move to the cloud and add proprietary code to their products to succeed," the article stated, citing the conclusion of venture capitalist Peter Levine at Andreessen Horowitz. "The current business model is recipe for failure."

"Levine says the conventional open source business model is flawed: Open source companies that charge for maintenance, support, warranties and indemnities for an application or operating system that is available for free simply can't generate enough revenue," the article states.

So I'm back to square one. Divio says the fact that successful companies are doing it proves its value. A venture capitalist says it can't succeed. Microsoft is doing it in a big way. Apple isn't doing it much at all. Red Hat is living it. What's the answer? Where's the data?

You tell me. Comment here or drop me a line. Why are for-profit companies open sourcing their software? I'm crowd-sourcing the open source question.

Posted by David Ramel on November 19, 20150 comments

Share

• LinkedIn
• Facebook
• Twitter

Even Microsoft Can't Make a Decent Android Emulator

If Microsoft had simply asked me first, I could've told them: Android emulation on Windows just doesn't work very well.

Mobile dev media are abuzz with news of problems with Project Astoria, part of Microsoft's much-ballyhooed effort to provide Universal Windows Platform Bridge toolkits that let developers build Windows apps for phones -- in Astoria's case by reusing their Android code.

Windows Central, on Friday the 13th, broke the story that there are problems with Astoria, described as a means to emulate Android apps on Windows. While neither confirming nor denying multiple reports of issues with the Astoria project, Microsoft provided the following "not ready yet" statement:

"We're committed to offering developers many options to bring their apps to the Windows Platform, including bridges available now for Web and iOS, and soon Win32. The Astoria bridge is not ready yet, but other tools offer great options for developers. For example, the iOS bridge enables developers to write a native Windows Universal app which calls UWP APIs directly from Objective-C, and to mix and match UWP and iOS concepts such as XAML and UIKit. Developers can write apps that run on all Windows 10 devices and take advantage of native Windows features easily. We're grateful to the feedback from the development community and look forward to supporting them as they develop apps for Windows 10."

Other bridge projects for Web apps, iOS apps and classic Win32 apps are reportedly still in the works. Windows Central noted that Astoria "was straight up emulation and could run into all sorts of legal and technical issues." Also, it said, "There are reports that the Android subsystem caused Windows 10 Mobile to slow down over time."

Well, that's something I -- and thousands of other Java developers working on Android apps from a Windows machine -- could have confirmed ahead of time. Android emulation using the Eclipse IDE with the Android Development Tools (ADT) plugin was horrible. Even with Android Studio, which Google last year put forth as the official replacement IDE for Android development, the emulation is without doubt the slowest piece of software I've ever had the misfortune to use. Creating an Android Virtual Device (AVD) to test out coding changes gobbled up tremendous amounts of RAM and brought my system -- any system, I'm thinking -- to a crawl.

The issue has brought up tons of comments on coding sites such as Stack Overflow ("Why is the Android emulator so slow? How can we speed up the Android emulator?") and Quora ("Why is the Android emulator so slow?") with no real satisfactory solutions having been found.

OK, so maybe it's a different kind of emulation from Astoria, but Android emulation and Windows just don't seem to mix.

Whatever the Astoria problems are, developers are left wondering about the project.

On the MSDN blog site, a May 10 posting announcing Astoria has practically gone dark, with several developers asking about the project but receiving no answers. The last post, published 11 days ago, asks:

"Is the 'Project Astoria Subsystem' for Windows 10 Mobile dead? From what I understand, Windows 10 Mobile Build 10586 was signed off my MS as the final build for the Threshold 2 release. According to a couple sites, that build does not contain the Project Astoria Subsystem. Does this mean that MS is abandoning the Project Astoria bridge/subsystem? Or is MS just not including it again until a later build of Windows 10 Mobile and if so, can anyone answer when they will put it back? I really think not having it will be a huge mistake as this is a huge advantage to close the 'App Gap' Windows phones have."

No one has answered those questions.

Posted by David Ramel on November 16, 20150 comments

Share

• LinkedIn
• Facebook
• Twitter