ReadWrite - application developmenthttp://readwrite.com/tag/application-development
enCopyright 2015 Wearable World Inc.http://blogs.law.harvard.edu/tech/rssTue, 31 Mar 2015 11:09:11 -0700Why Web Tools Like AngularJS Need To Keep Breaking Themselves<!-- tml-version="2" --><div tml-image="ci01be4fadd0012a83" tml-image-caption=""><figure><img src="http://a3.files.readwrite.com/image/upload/c_fill,cs_srgb,dpr_1.0,q_80,w_620/MTI1NjI1NDQ1NDAzMDc3MjUx.jpg" /><figcaption></figcaption></figure></div><p>As the line between native and Web applications increasingly blurs, more developers are turning to <a href="http://readwrite.com/2014/02/06/angular-backbone-ember-best-javascript-framework-for-you">Web application frameworks like AngularJS</a>. AngularJS, developed and open sourced by Google, has been especially hot, whether measured by <a href="http://www.google.com/trends/explore#q=AngularJS%2C%20EmberJS%2C%20%2Fm%2F06y_qx%2C%20Meteor.js%2C%20Backbone.js&amp;date=1%2F2013%2022m&amp;cmpt=q">general interest</a>, <a href="http://www.indeed.com/jobtrends?q=AngularJS%2CEmberJS%2CMeteor.js%2CBackbone.js&amp;l=">jobs</a>, or <a href="http://www.infoworld.com/article/2612250/application-development/the-10-hottest-javascript-framework-projects.html">open source contributions</a>, largely due to <a href="http://readwrite.com/2014/09/08/simple-technology-hard-not-easy-angularjs-nosql">its ease of use</a>.&nbsp;</p><blockquote><p><strong>See also: <a href="http://readwrite.com/2014/11/04/emberjs-javascript-framework-we-dont-need-to-break-the-web">Innovating Fast And Slow: EmberJS Insists "We Don't Need To Break The Web"</a></strong></p></blockquote><p>But not everyone is happy. According to AngularJS critic-in-residence Danny Tuppeny, the AngularJS development community has "<a href="http://blog.dantup.com/2014/10/have-the-angular-team-lost-their-marbles/">lost its marbles</a>" of late. But is his criticism valid?</p><h2>Why AngularJS?</h2><p>AngularJS is a popular Web application framework—a collection of JavaScript code libraries, templates and other software intended to make it easier for developers to build dynamic Web pages or Web apps.</p><blockquote><p><strong>See also: <a href="http://readwrite.com/2014/09/08/simple-technology-hard-not-easy-angularjs-nosql">Why Even Simple Technology Can Be Hard For Developers</a></strong></p></blockquote><p>Web frameworks are hot in general, but AngularJS is blisteringly so, as measured by relative growth in job postings:</p><div tml-image="ci01be4f03c001efe2" tml-image-caption="Source: Indeed.com Job Trends"><figure><img src="http://a5.files.readwrite.com/image/upload/c_fill,cs_srgb,w_620/MTI1NjI0NzE1Nzk1NTU4Mzcw.png" /><figcaption>Source: Indeed.com Job Trends</figcaption></figure></div><p>There are several reasons for this popularity, and Starsheet VP of Products <a href="http://code.tutsplus.com/tutorials/3-reasons-to-choose-angularjs-for-your-next-project--net-28457">Adam Conrad names three</a>:</p><ol><li><em>It's Google-approved</em>: "Angular is built and maintained by dedicated (and highly talented) Google engineers. This means you not only have a large open community to learn from, but you also have skilled, highly-available engineers tasked to help you get your Angular questions answered"</li><li><em>It's comprehensive:</em> "No other plugins or frameworks are necessary to build a data-driven web application"</li><li><p><em>It's easy:</em> "With a few attributes added to your HTML, you can have a simple Angular app up in under 5 minutes"</p></li></ol><p>These are good reasons to use AngularJS. It turns out, however, that there are some pretty strong reasons not to, some of which emerge in the comments section of Conrad's article.</p><h2>Why Not AngularJS?</h2><p>Some criticisms are particularly focused.&nbsp;Tom Dale, one of the creators of EmberJS, a rival framework, worries that AngularJS may be attempting too much:</p><p>Dale is, of course, biased, and occasionally lets it show in <a href="https://storify.com/marcslove/tom-dale-angular-rant">rants like this one</a>.&nbsp;</p><p>But he also has a valid point, one that comes through even more strongly in Tuppeny's broadside. For Tuppeny, the problem with AngularJS isn't its ambition or its pace of development, but rather the way it routinely leaves developers behind:</p><blockquote><p>Our current codebase has parts that are over 10 years old; and we hope our new codebase will last this long too. It seems that if we start writing Angular today; we’ll be forced to rewrite the frontend in three to four years at latest (and with the way apps are going, the frontend is likely to be a large codebase). This doesn’t sound very attractive.... We need frameworks that are stable and supported long-term; not that are constantly inventing new concepts and being rewritten with breaking changes every 5 minutes. Of everyone, Google should know how hard it is to maintain large web apps</p></blockquote><p>Google and the AngularJS community, in other words, may be acting like... well, Google, which regularly dumps or revamps its Web applications after just a few short years. This is par for the course with fast-moving Web companies, but may not fit a more staid enterprise application lifecycle.</p><p>Which may be the point.</p><h2>AngularJS: Breaking By Design</h2><p>We don't live in a world with 10-year product lifecycles anymore. If your company does, you may want to find a new job.&nbsp;As Ars Tempo founder <a href="http://blog.dantup.com/2014/10/have-the-angular-team-lost-their-marbles/#comment-1660823110">Zlatko Đurić writes</a>:</p><blockquote><p>[W]e should rebuild our components every 3-5 years anyway. Do you still write code the same way you did 4 years ago? If yes, then why using angular in the first place, why not just use components you've built your stuff with before it? Using the same browser APIs, the same things you relied on in the past?</p></blockquote><p>The payoff is worth it, he continues:</p><blockquote><p>To me, it's still the ... ideas that power the Angular framework that matter. Like DI and data binding. Those things make me able to develop a new webapp in 3 weeks instead of 3 months. That's what matters. And if in 5 years, when I'm two years into Angular2, somebody asks me to extend my old app built with 1.2, I'll probably be pissed at how verbose or stiff the old Angular API was. Or that I can't just use a finished component for it.</p></blockquote><p>AngularJS developer Pascal Precht&nbsp;<a href="http://blog.dantup.com/2014/10/have-the-angular-team-lost-their-marbles/#comment-1659307719">echoes</a> this sentiment:</p><blockquote><p>I think before you judge about the new templating syntax that comes with Angular 2.0, [Tuppeny] should at least mention why that is. The next version of Angular is built for the future. That means, embracing technologies like Web Components. In order to do that, Angular has to be rewritten, since the current version of it sits on top of a design made like 4 years ago.</p></blockquote><p>The Web, in other words, pushes us forward, and AngularJS seems to be willing to sacrifice backward compatibility to get there. Yes, it probably could be done more cleanly, with less heartache for developers. But no, the alternative is not to comfortably recline in the easy chair of the current Web.&nbsp;</p><p>The Web, after all, will force us to continuously break with the past, perhaps more often than is comfortable. But that's the pace at which innovation goes today.&nbsp;</p><p>There is no rest, saith the Web, for the application developer.</p><p><em>Lead image courtesy of <a href="http://www.shutterstock.com">Shutterstock</a></em></p>Backward compatibility may be a casualty of Internet speed.http://readwrite.com/2014/10/30/angularjs-javascript-framework-web-tools-need-to-break-themselves
http://readwrite.com/2014/10/30/angularjs-javascript-framework-web-tools-need-to-break-themselvesHackThu, 30 Oct 2014 09:54:21 -0700Matt AsayAs Systems Get More Complex, Programming Is Getting "Reactive"<!-- tml-version="2" --><p>Hardware keeps getting smaller, more powerful and more distributed. To keep up with growing system complexity, there's a growing software revolution—called “reactive” development—that defines how to architect applications that are going to participate in this new world of multicore, cloud, mobile and Web-scale systems. </p><div tml-image="ci01b7298abdb7860e" tml-image-caption="Jonas Bonér" tml-render-size="small" tml-render-position="right"><figure><img src="http://a3.files.readwrite.com/image/upload/c_fill,cs_srgb,dpr_1.0,q_80,w_620/MTE5NDg0MDYzNzg1NDUzMDcx.jpg" /><figcaption>Jonas Bonér</figcaption></figure></div><p>One of the leaders of the reactive-software movement is distributed computing expert and <a href="http://typesafe.com/">Typesafe</a>&nbsp;co-founder and CTO Jonas Bonér, who published the original Reactive Manifesto in September 2013.&nbsp;</p><p>Similar to the early days of the "agile" software development movement, reactive programming got early traction with a hardcore fan base (mostly functional programming, distributed computing and performance experts) but is starting to creep into more mainstream development conversations as high-profile organizations like <a href="http://www.infoq.com/interviews/jafar-husain-netflix-reactive-programming-rx">Netflix</a> adopt and evangelize the reactive model. </p><blockquote><p><strong>See also: <a href="http://readwrite.com/2014/09/17/netflix-chaos-engineering-for-everyone">Netflix's Chaos Engineering Should Be Mandatory—Everywhere</a></strong></p></blockquote><p>I caught up with Bonér to ask him about reactive's traction on the eve of publishing version 2.0 of the <a href="http://www.reactivemanifesto.org/">Reactive Manifesto</a>. Beware: This stuff gets deep very quickly.</p><h2>A Reactive Solution To Broken Development</h2><p><em><strong>ReadWrite</strong>: </em><em>So what’s </em>not<em>&nbsp;reactive about software today, and what needs to change? </em></p><p><strong>Jonas Bonér</strong>: Basically what’s “broken” ties back to software having synchronous call request chains and poor isolation, yielding single points of failure and too much contention. The problem exists in different parts of the application infrastructure.</p><p>At the database layer, most SQL/RDBMS databases still rely on a thread pool or connection pool accessing the database through blocking APIs. So if you exhaust the thread pool by blocking all available threads then everything stops. This problem goes all the way down to the native drivers that the vendors provide, and the JDBC standard specification (for accessing relational databases)—which doesn’t support non-blocking/asynchronous access.&nbsp;</p><p>It will take years before it’s supported. </p><p>In the service layer, we usually see a tangled mix of highly contended, shared mutable state managed by strongly coupled deep request chains. This makes this layer immensely hard to scale and to make resilient. The problem is usually “addressed” by adding more tools and infrastructure; clustering products, data grids, etc. But unfortunately this won’t help much at all unless we address the fundamental underlying problem.&nbsp;</p><p>This is where reactive can help; good solid principles and practices can make all the difference—in particular relying on share nothing designs and asynchronous message passing. </p><blockquote><p><strong>See also: <a href="http://readwrite.com/2014/07/10/akka-jonas-boner-concurrency-distributed-computing-internet-of-things">How One Developer Set Out To Make The Internet Of Things Manageable</a></strong></p></blockquote><p>In the Web layer, we often see request chains executed in a completely serial fashion, meaning that the response time is the sum of the time it takes to do everything, which can sometimes be hundreds of different service calls. This means that keeping latency under control—bounded, within the SLAs and predictable—while allowing for scale, is both technically very challenging and requires a lot more hardware thanks to inefficient usage of resources.&nbsp;</p><p>In a reactive application you would split up the work in many small composable chunks and run them in parallel—which will bound the latency to a max of the longest performing chunk and make very efficient use of the resources available. </p><p>There are many other ways that today’s software is not reactive, but those are a few of the big ones.</p><h2>Defining Reactive</h2><p><em><strong>ReadWrite</strong>: </em><em>What’s the goal of the reactive movement? What are you trying to accomplish?</em></p><p><strong>JB</strong>: A lot of companies have been doing reactive without calling it "reactive" for quite some time, in the same way companies did agile software development before it was called "agile." But giving an idea a name and defining a vocabulary around it makes it easier to talk about and communicate with people. It makes it easier to explain and bring to market a set of principles that are known to work well together. </p><p>Not everyone’s view of agile fits into the agile definition, but what has become agile—and the reason for all these experts to write up the <a href="http://agilemanifesto.org/">Agile Manifesto</a>—is that they knew which principles worked well together and completed each other in a cohesive story.&nbsp;</p><p>This is what reactive is all about. We found these core principles to work well together in a cohesive story. People have used these approaches years before, but this grouping and this reactive story has meaning, in the same sense of agile. And it provides a baseline for solving problems against the wish-list of application behavior that everyone wants. </p><h2>The Future Of Reactive Programming</h2><p><em><strong>ReadWrite</strong>: </em><em>What are the next steps for the reactive movement? </em></p><p><strong>JB</strong>: The reactive principles trace all the way back to the 1970s&nbsp;(e.g., <a href="https://en.wikipedia.org/wiki/Tandem_Computers">Tandem Computers</a>) and 1980s (e.g., <a href="https://en.wikipedia.org/wiki/Erlang_(programming_language)">Erlang</a>), but scale challenges are for everybody today. You don’t have to be Facebook or Google anymore to have these types of problems. There’s more data being produced by individual users, who consume more data, and expect so much more, faster. There’s more data to shuffle around at the service layer; replication that needs to be done instantaneously, and the need to go to multiple nodes almost instantaneously.&nbsp;</p><p>And the opportunities have changed, where virtualization and containerization make it easy to spin up nodes and cost almost nothing—but where it’s much harder for the software to keep up with those nodes in an efficient way.</p><p>So in many ways the next steps for reactive are to just keep refining its view of that problem set—and the application characteristics that developers should aspire to—to conquer them. Martin Thompson, Roland Kuhn, Dave Farley and I have in fact just rewritten the <a href="http://www.reactivemanifesto.org">Reactive Manifesto</a>, taking a lot of great feedback we have been getting from the community into account, distilling it into a much shorter and simpler document. </p><p>But the big next step for Reactive is expanding beyond principles, to also bring in more specific tools, techniques, patterns and best practices, thereby making it approachable for the masses.&nbsp;</p><p>We are planning to write an appendix to the Reactive Manifesto in which we can dive in and provide more hands on practical advice on how to design and implement reactive systems. We’re also starting to see more vendors provide solutions and tools that support building reactive systems, more technical books being published about reactive, and more presentations (and and even full tracks) at events tied to reactive—so this is already happening.&nbsp;</p><p>One good example of this is the <a href="http://reactconf.com">React</a> conference that I’m helping to organize, which will be a great place to learn how to build reactive systems from some of our top thought leaders in the industry and discuss its principles and practices.</p><p><em><strong>ReadWrite</strong>: </em><em>What are the green field areas that you think will drive the requirements for reactive in the future?</em></p><p><strong>JB</strong>: There are several:</p><ol><li>One interesting area that has a lot of debate is around “microservices”—which basically is a conversation around what the smallest ideal isolation of a single “service” and its behavior looks like.&nbsp;</li><li>Another is the emerging need is to stream large volumes of potentially infinite data streams in real-time, while keeping latency predictable and without overloading the server.&nbsp;</li><li>This ties in to the rising need of reactive Big Data solutions (sometimes called “fast data”)—providing (close to) real-time analytics and data processing.&nbsp;</li><li>Internet of Things is another huge driver for new approaches to application infrastructure, where machines and devices are generating new challenges for managing and replicating bursts of data throughout distributed environments, and where individual nodes have new requirements for starting/stopping/dealing with failure based on events. &nbsp;&nbsp;</li></ol><p><em>Lead photo by <a href="https://www.flickr.com/photos/dominik99/384027019">nerovivo</a></em></p>A new way to develop for the cloud.http://readwrite.com/2014/09/19/reactive-programming-jonas-boner-typesafe
http://readwrite.com/2014/09/19/reactive-programming-jonas-boner-typesafeHackFri, 19 Sep 2014 05:00:00 -0700Matt AsayWhy Cloud Development Environments Are Better Than Desktop Development<!-- tml-version="2" --><div tml-image="ci01b2823e40018266" tml-render-position="center" tml-render-size="large"><figure><img src="http://a2.files.readwrite.com/image/upload/c_fill,cs_srgb,dpr_1.0,q_80,w_620/MTIyMzAzMzQyNjkyMDQxMzE4.jpg" /></figure></div><p><em>Guest author Tyler Jewell is CEO of <a href="https://codenvy.com/">Codenvy</a>, a cloud development environment.</em></p><p>Over the past decade, cloud computing has disrupted nearly every facet of IT. Sales, marketing, finance and support - all of these applications are being reengineered to take advantage of cloud's instant access, no download and pay-as-you-go attributes. According to Gartner, the cloud is changing the way applications are designed, tested and deployed, resulting in a significant shift in application development priorities. Cost is a major driver, but so are agility, flexibility and speed to deploy new applications. The firm estimates that <a href="http://www.gartner.com/id=2098416">90% of large enterprises and government agencies will use some aspect of cloud computing</a> by 2015.</p><p>The cloud has also begun to impact the tools and support solutions that drive IT. This includes performance management (<a href="http://www.newrelic.com/">New Relic</a>), backup and recovery (<a href="http://www.mozy.com/">Mozy</a>), configuration management (<a href="http://www.servicenow.com/">Service Now</a>), helpdesk (<a href="http://www.zendesk.com/">Zendesk</a>), datacenter automation (<a href="http://www.puppetlabs.com/">Puppet Labs</a>) and release management. The agility afforded by on-demand services is further penetrating the developer space.</p><p>We've seen cloud versions of middleware in the form of Platform-as-a-Service (PaaS), agile solutions (<a href="http://www.rallydev.com/">Rally Software</a>), Code Versioning Systems (CVS) (<a href="http://www.github.com/">GitHub</a>), continuous integration (<a href="http://www.cloudbees.com/">CloudBees</a>) and system testing (<a href="http://www.soasta.com/">Soasta</a>). The more than 100 companies in these segments have cumulatively raised more than $500 million in capital.</p><p>Yet despite this transformation, there has been little disruption to the <a href="http://en.wikipedia.org/wiki/Integrated_development_environment">integrated development environment (IDE)</a> world. The world's nearly 15 million developers, teams and organizations continue to use <em>desktop</em> IDEs as their workbench of choice. Why hasn’t the development environment moved to the cloud along with just about every other application?</p><h2>What's Wrong With Desktop Development?</h2><p>Desktop development environments are becoming outdated, failing more often and causing productivity issues for developers. Here's why:</p><p><strong>Complicated configuration management:</strong> The substantial configuration management process&nbsp;for a developer's workspace turns developers into part-time system administrators, responsible for their own mini-data center running entirely on the desktop. This is time consuming, error prone and challenging to automate.</p><p>Many developers have multiple computers and are forced to repeat these tasks on each machine. There is no way to synchronize the configurations of components across different&nbsp;machines, and each machine requires similar hardware and operating systems to&nbsp;operate the components identically.</p><p><strong>Decreased productivity:</strong> Many IDEs are memory and disk hogs, with significant boot times. They are so resource-hungry they can starve other applications, such as the Web browser. The net effect is a less productive developer due to a slower machine.</p><p><strong>Limited accessibility:</strong> Desktop developer workspaces are not accessible via mobile devices. Developers who need remote access have to resort to complex and slow solutions such as GotoMyPC - if their firewall allows it.</p><p><strong>Poor collaboration:</strong> These days, most developers work as part of a team, so&nbsp;communication and collaboration are critical. But desktop IDEs must outsource collaboration to communication systems outside the developer's workflow, forcing developers to continuously switch between developing within the IDE and communicating with their team via other means.</p><h2>The Solution: Cloud Development</h2><p>To solve these problems requires moving the entire development workspace into the cloud. The developer's environment is a combination of the IDE, the local build system, the local runtime (to test and debug the locally edited code), the connections between these components and the their dependencies with tools such as <a href="http://en.wikipedia.org/wiki/Continuous_integration">Continuous Integration</a> or central services such as Web Services, specialized data stores, legacy applications or partner-provided services.</p><p>The cloud-based workspace is centralized, making it easy to share. Developers can invite&nbsp;others into their workspace to co-edit, co-build, or co-debug. Developers can communicate with one another in the workspace itself - changing the entire nature of pair programming, code reviews and classroom teaching. The cloud can offer improvements in system&nbsp;efficiency &amp; density, giving each individual workspace a configurable slice of the available memory and compute resources.</p><p>Of course there is more work to do, and we are far from tapping into the&nbsp;endless possibilities the cloud computing offers developers. But the benefits are already clear.</p><p></p><p><em>Image courtesy of <a href="http://www.shutterstock.com">Shutterstock</a>.</em></p>Most of the world's nearly 15 million developers continue to use desktop IDEs as their workbench of choice. Why hasn’t the development environment moved to the cloud along with just about every other application?http://readwrite.com/2013/04/16/why-cloud-development-environments-are-better-than-desktop-development
http://readwrite.com/2013/04/16/why-cloud-development-environments-are-better-than-desktop-developmentCloudTue, 16 Apr 2013 05:05:00 -0700Tyler JewellHTML5: Alive And Well With CIOs<!-- tml-version="2" --><div tml-image="ci01b28232b0078266" tml-render-position="center" tml-render-size="large"><figure><img src="http://a4.files.readwrite.com/image/upload/c_fill,cs_srgb,dpr_1.0,q_80,w_620/MTIyMzAzMjkzMDMxNDgxOTU4.jpg" /></figure></div><p>Apparently, native apps have won. We even <a href="http://readwrite.com/2013/04/01/the-facebook-phone-the-triumph-of-native-apps-over-html5">said so</a> right here on ReadWrite. After all, Facebook apparently likes native more.&nbsp;</p><p>Unfortunately, CIOs missed the memo, and the dirty little secret is that most of the world's software, including apps, is written for use, not sale. That means that most of the world's software is not going to follow what Facebook's mobile strategy is, but rather what those stodgy enterprises do.</p><p>Those stodgy enterprises? They're all in on HTML5.</p><p>I spent Wednesday afternoon with a who's who of enterprise CIOs and CTOs in New York City, talking about Big Data, cloud and mobile. With the Facebook Phone in mind, I polled the group on its mobile applications. Every single executive - not one exception - was building hybrid HTML5 apps, meaning the bulk of the app is written in HTML5 with a native wrapper to improve performance, add camera access, etc.</p><p>Every. Single. One.</p><p>And not just a few such apps. The bulk of their apps were hybrid HTML5 apps, both for internal employees and for external customers.&nbsp;</p><h2>Going Native?</h2><p>Sure, there were some native apps, though generally not yet written for Android. ("We can't figure out what to do about Android," said one executive of a major financial services firm.) But overall, the CIOs I talked to, and there were roughly 100 in the room, were basing their mobile app strategy on hybrid HTML5 apps.</p><p>The CIO needs are different from Zynga's, or those of other consumer app developers. Many of the apps they're building are informational in nature, or have such a stringent need for broad access that these enterprises simply can't afford to alienate a particular mobile device demographic. They need to support iOS, Android, Windows, Blackberry, etc. And with the vast majority of mobile OSes now sporting HTML5-compatible browsers, the time is ripe for HTML5 apps.</p><h2>Still Hiring For HTML5</h2><p>The job numbers bear this out. While HTML5 can get pooh-poohed by consumer app developers like Facebook, it remains&nbsp;<a href="http://www.indeed.com/jobtrends?q=HTML5%2Cios%2Candroid&amp;l=">the hottest technology skill</a>, as measured by jobs, more than holding its own with iOS and Android in absolute number of jobs:</p><div tml-image="ci01b2823340018266"><figure><img src="http://a2.files.readwrite.com/image/upload/c_fill,cs_srgb,w_620/MTIyMzAzMjk0OTEwNTI0Njk3.png" /></figure></div><p>And trouncing both iOS and Android in terms of relative job growth:</p><p>This corroborates <a href="http://www.evansdata.com/press/viewRelease.php?pressID=185">Evans Data's finding in early 2012</a> that 75% of mobile developers were using or expecting to use HTML5, a number that seems to have moved from aspirational to actual in 2013.&nbsp;</p><p>Hence, while the media will tend to focus on what it knows best - consumer apps - CIOs are working away on HTML5 strategies. Just <a href="http://www.forbes.com/sites/ciocentral/2013/01/23/html5-vs-native-mobile-apps-myths-and-misconceptions/">ask Accenture</a>. Yes, there are <a href="http://css.dzone.com/articles/building-mobile-applications">tradeoffs when going HTML5</a>, just as there are tradeoffs when going native. For enterprise CIOs, however, broad, cross-platform access to employees and customers makes HTML5 a winning solution.</p><p><em>Image courtesy of <a href="http://www.shutterstock.com">Shutterstock</a></em>.</p>While it's true that consumer app developers seem to have settled on native apps, enterprise CIOs have different needs and a very different strategy. http://readwrite.com/2013/04/05/html5-alive-and-well-with-cios
http://readwrite.com/2013/04/05/html5-alive-and-well-with-ciosMobileFri, 05 Apr 2013 07:00:00 -0700Matt Asay