Archive for Web

Hybrid Today, Progressive Web App Tomorrow

App (and I am using that term very loosely here) development has undergone a change. Most companies are eschewing high cost native development and for iOS and Android and going with hybrid solutions using tools like Xamarin or Ionic. This is a great way for organizations to lower their initial development and ongoing maintenance costs as well as get a useful app for their business needs. One area that many organizations are finding is that they still need desktop web applications and you don’t get the code sharing advantages between mobile and desktop platforms that you do between the two dominant mobile platforms – iOS and Android. Luckily, the march of development tools and frameworks has carried on and there’s a new solution – progressive web apps. These are web applications that live on the server but thanks to powerful JavaScript (or in some cases Typescript) can access native-like device capabilities. This, coupled with responsive development techniques and some adaptive CSS allows the app to scale in not only screen-size but also capabilities depending on the device. There are a number of frameworks that provide this, but my two favorites are Angular 4 and Polymer 2.

The Angular team now uses the tagline “one framework, mobile and desktop” and they mean it. Angular has come a long way from the original release of AngularJS and is now a full application development framework.  Currently, Angular is on version four and if you’ve used an older version of the framework you’re going to find major differences (especially in the area of routing) but the time invested into catching up is well worth it. Using Angular 4 you can now create a high-functioning application that runs on everything from your twenty-seven inch desktop screen all the way down to a mobile phone. I do find that there’s a bit more ceremony in the latest versions of Angular than in the first, but you could argue that’s an advantage, since it also makes the framework more flexible than its predecessor.

Polymer 2 is more focused on JavaScript components than Angular but is no less powerful. While the details of it works under the hood are different the end result is exactly the same — you end up with a powerful application that can scale for different screen sizes and devices.  If I had to make a comparison between Angular and Polymer 2, it would be that the Polymer team has made more of an effort to be “pure JavaScript.” I don’t love that criticism of Polymer for two reasons: 1) Angular is now written in Typescript and I (in my opinion) best consumed using Typescript and 2) some of the custom directives in Angular actually lead to less boilerplate than the more “pure JavaScript” alternatives in Polymer (especially around defining custom components), so I’d actually consider that a feature for Angular rather than a bug. Still, that doesn’t mean that Polymer is not a great choice for your progressive web app development needs.

There are of course other choices for developing progressive web apps but these two projects have the backing of Google and large communities around them, so they’re likely going to stand the test of time unlike the many <insert_noun.js>  JavaScript frameworks of the previous ten years.  The future looks bright for the progressive web app and by extension Angular and Polymer, given that the trend of businesses demanding more for less out of their developers and development partners is likely to continue.

If you liked this post, follow me on Twitter for more!

How I Missed Web Assembly

As pointed out by an intrepid Coder Radio listener, I totally missed the importance of Web Assembly when it was in its initial nascent phases a year or so go. Now that Web Assembly is going to become a standard endorsed by the W3C and has backing from at least two major browser vendors to date (Google and Mozilla), I’ve done a full 180 and am convinced it is the future of not only web development but probably a good deal of mobile and desktop development as well; my assumption is that tools like Ionic and Electron will be able to leverage the performance gains brought by web assembly as well.

Looking back my mistake was that I failed to parse out the signal from the noise in the wider JavaScript conversation circa 2014 and on. There was (and in many communities still is) a lot of angst about the short-comings in the JavaScript language and a lot of people making noise about using alternatives to it that would simply compile to it –  CoffeeScript and TypeScript for example. There was of course a thread in the background about Web Assembly becoming potentially a language agnostic solution to this problem, but because I was looking at it through the lens of alternative languages to JavaScript and at the time didn’t think and I still don’t think  that changing from JavaScript just because you want a different language but then compiling into JavaScript makes any sense at all. In other words, I took a breathe and shouted a hearty “get off my lawn!”

My curmudgeon-like tendencies aside, I still firmly standby the idea that just writing in something like CoffeeScript to compile into JavaScript just because you don’t some features or shortcomings of JavaScript is silly. What I missed was that this whole language brouhaha was just a minor prologue to the real story — Web Assembly. Moving to Web Assembly not only increases web application performance significantly but also (as more languages create compilers for it) gives those developers who prefer some language over JavaScript a much more reasonable choice; they can simply use the language of their choice and compile it directly to Web Assembly! I’m totally on-board with that. In fact, I’ve been working in Microsoft’s TypeScript and find it great, so if we actually make it (we probably will) to this Web Assembly world, then I’ll probably go Typ eScript for most greenfield projects going forward.

As in Eden, there’s a potential snake in our garden — Apple. Web Assembly being fully supported on mobile Safari for iOS is absolutely necessary to unleash the full potential and development efficiencies that I believe Web Assembly can over the next five year period bring.

Questions? Comments? Blood curdling nerd rage? Tweet me! Also, take advantage of my free strategy session for your next project!

Wither Webkit?

As you are probably aware Google has forked Webkit and will be calling their fork Blink. Google does not intend to re-merge with the main project at any point in the future and is signaling that they will be adding new features to their rendering engine. As a developer who often has to work on the web or mobile web this is very interesting but also a little concerning.

 

Currently, Blink and Webkit are just about identical, so we can still feel secure in our Webkit “monoculture”, but the situation will likely change in a year or less. Even if Google makes an effort, as some have suggested that they might, to not break standards or chooses not to push Blink specific features, web developers are still going to have to deal with yet another rendering engine. Sure we’ve already been dealing with a number of them and have gotten used to having to append our CSS with “–webkit” or “–moz”, but Google is not adding a “–blink”. Instead, developers will have to dig into a settings screen to enable or disable functionality. Bottom line there is that there will be Blink specific functionality that some developers will likely want to user; for example currently NACL only works on Chrome and Dart VM works best on Chrome – in other browsers code written in Dart has to translated into traditional JavaScript. There are also a number of rumors floating around that Blink may focus on optimizing HTML5 graphics performance on ARM devices.

 

The question really becomes not what Google is going to do with Blink but rather what are the rest of the Webkit team going to do without them? Google and Apple have been the driving forces around the project and more and more Google has been taking point on a lot of the more cutting edge issues; for example, Google has been pushing performance more than any other contributor to the project but, for the most part, Apple and others have been able to benefit from Google’s efforts thanks to the free software nature of the project’s license. Given Apple’s less than enthusiastic embrace of developers using web technologies to develop for their platforms, it seems unlikely that they would be inclined to match Google’s pace. In a lot of ways, give that Apple’s business model is to sell expensive hardware, a good browser is just another feature on an Apple device, however, for Google, the browser is the primary platform.

Progress is a good thing for web and I am confident that Google’s decisions will yield web developers some pretty cool tech to work with, but there is also the risk that web developers will start relying on those tools too much and we will end up back in an IE 6 / ActiveX situation. Questions? Comments? Dogmatic rage? Please feel free to contact me on Google+ or Twitter. This post was brought to you by Code Journal for Mac.

ASP.Net — Good, Just Not for Me

If you’ve been listening to recent Coder Radio episodes or following this blog, then you probably know that I have been working on a side project (that I am no longer pursuing due to intense competition in the space and a general lack of interest on my part) in Microsoft’s ASP.NET MVC 4 and Windows Azure.  Overall, I really liked the developement experience of the stack and Visual Studio is still the best IDE (if you like that sort of thing) on the market today and of course C# was a delight to work in. Unfortunately, the downsides are just not acceptable for the type of projects I work on or first party products I plan to develop; those downsides being the cost of Azure, the cost of SQL Server, and Windows Server.

Azure is awesome. In a lot of ways it is very similar to Heroku: it has easy to configure Git deployment and is easy to configure and deploy. Unfortunately, it also shares Heroku’s penchant for premium pricing. To be clear, both services are great for prototyping or event the 1.0 versions of a project, but  if your project hits any sort of scale, you are going to be looking at some pretty hefty hosting costs.

SQL Server is interesting. I don’t know too much about it as it compares to databases I use on a regular basis (ie PostgreSQL). When I started looking into it, I was quickly derailed by cost. That’s right SQL server is one of those things that if you have to ask how much it cost you can’t afford it and that certainly turned out to be true for me. Though Azure does support MySQL, the default (and presumably prefered) implementation of MVC 4 is best used with SQL Server. Due to the aforementioned Azure hosting costs, I would likely want to migrate any successful projects onto dedicated servers or VPSs and that would mean having to pay for SQL Server licensing fees.

Speaking of licensing fees, let’s not forget Windows Server. To be fair, the cost of Windows Server is a lot less than SQL Server and seems to rolled into a lot of monthly VPS plans. Still, I really don’t like a lot of the decisions Windows Server makes, though Microsoft has made some effort to address this issues in Windows Server 2012. In a lot of ways I just prefer working with a Linux (Ubuntu if at all possible)  server over Windows.

The natural question you may have is: “since you are scrubbing the project and don’t plan to use anything you may have learned about the stack, didn’t you just waste a lot of time?” I don’t think so. For one, I always feel that it is a good idea to broaden your horizons technically. More importantly, it was good to see how things are done in the more Windows centric world and it was a joy to interact with the .Net community. Comments? Questions? Share them with me on Google+ or Twitter. This post was made possible by Code Journal and Fingertip Tech, INC. If you are Github user please check out Code Journal and if you are interested in having an Android, iOS, or web app developed please contact me.

Happy Thanksgiving 2012 Open-Source!

I had a wonderful Thanksgiving this year and, as is common this time of year, friends and family made the normal mentions of things, places, people, or any other sort of noun that they are thankful. Of course, I agree with the most common objects of gratitude: friends, family, etc. However, I got to thinking about work and how thankful I am for the proliferation of open-sourced software. So, I’ve compiled this list of software libraries that I am most thankful for this year.

ASIHTTPRequest: Admittedly, this is a bit older than some of its more popular competitors and there are reasons that one might choose an alternative, but you just can’t be a simple networking interface that includes easy to use caching support. AFNetworking may be the hot new kid on the block, but ASI is still more than adequate for the job. I can’t promise that ASIHTTPRequest will still be my networking framework of choice in 2013 but it has served me well for the last two years and is even a joy to maintain on older apps.

jQuery: Compared to most client-side development, web development is awful. jQuery aims to take pain out of web development and, for the most part, does the job. In the last year, I don’t think I worked on any sites or web apps that did not use at least part of jQuery. I’m sure jQuery will continue to be the ‘go to’ tool for web developers everywhere in 2013.

Rails: Rails has been all over the place this year. I’m very thankful to have had the opportunity to work with it and for it to be introduction to Ruby. For me 2012 was the year of Rails on the backend, however, I doubt that will hold true for 2013. From a consulting perspective, Rails seems to be losing ground to Python-based alternative such as Django and the upstart Node.js. From a more personal perspective, Rails is solving problems I don’t seem to have or rather I have those problems but there are also other issues that it chooses to ignore. Additionally, Rails is going, as is true to its nature, in its own direction (think SASS and Coffeescript) and, in more and more cases, those just aren’t paths I am interested in taking. I have been evaluating alternatives and have come to a decision stay tuned for another post later next week.

There are other projects that I’ve used or use frequently, but these are three that stick out most prominently. Will they all be on next year’s list? Doubtful. Still, I am thankful for them and all the open-source work that makes my job easier and, in some cases, possible. Do you have your own three? Share them with me on Google+ or Twitter. This post was made possible by Code Journal and Fingertip Tech, INC. If you are Github user please check out Code Journal and if you are interested in having an Android, iOS, or web app developed please contact me.

A Look at Azure and MVC 4

ASP.Net MVC 4 is amazing. There I said it! I know I’m supposed to be the ‘Mac guy’ or ‘Linux guy’ or possibly even the ‘Ruby / Rails guy’ depending on where you know me from but the truth is that I love all technology and often find myself trying out new platforms or playing with some shiny tech toy. For the last month or so ASP.Net MVC 4 has been that new toy along with Windows Azure.

The Good

Azure provides easy to use web-based GUI’s for basically everything you’d want to do to configure, administer, and monitor your app. If you’re not a fan of GUI’s, there are also commandline tools for Windows and Mac.

For you Heroku lovers out there, the MVC / Azure development and deployment experience is very similar to the Rails / Heroku experience. In fact, Microsoft has gone so far as to build in Git deployment to Azure and has even provided an easy to use web-based GUI tool for setting it up. Overall, I was really impressed with what I saw.

Visual Studio still rocks. I’ve been working with Visual Studio 2012 and have been loving the code generation and debugging tools it includes. It simply is one of the most advanced IDE’s on the market today.

Microsoft has come along way since the days of IE 6. .Net’s Razor View Engine provides full support for HTML5. Not only was I happy to see this, but I was also a little surprised to see how far they’ve come in the area of web standards.

The Bad

MVC 4 has one achilles heel: price. Azure itself, like Heroku is expensive, but with Heroku you can, though with a bit of effort, migrate to a generic Linux server. The issue with Azure is that you’d have to pay for a Windows server license and other licensing fees if and when you want to migrate off of Azure. However, the costs can really start to pile on when you factor in Microsoft SQL Server.

The Ugly

There’s not much ugly in the Microsoft web development stack these days.

The Bottom Line

Overall I am very impressed with what I saw and will be keeping a close eye on ASP.Net and Azure. If you’ve been a Rails or Django developer and have never taken a look at the Microsoft stack, Azure and MVC 4 are definitely the place to start.

Shared Hosting Git Deployment

HostGator has been my registrar of choice since I first registered my first domain; however, I have also register a few domains with GoDaddy and (far fewer) with Domain.com. Initially, my needs were simple: give me an easy WordPress or Joomla install and I was happy than a pig in slop. Times, however, have changed. With the exception (somewhat ironically) of this site, I no longer work on WordPress or Joomla sites and instead tend to do more direct web development or ship sites on Rails or some other web development framework. This shift in development platform and time / experience have of course brought a number of other changes with them. For one I am now a big proponent of continuous deployment in the web development space; I’ve been deploying new versions of Fingertip Tech, INC’s website every day since this new redesign.

Unfortunately, the site is hosted on a shared hosting account rather than a ‘real server,’ so I was relatively sure that I was doomed to FTPing my changes up to the host each time  I made a change; in my defence, I was developing a small Ruby script that would FTP changes up based on Git commits. As luck would have it, that wasn’t necessary.

As luck would have it HostGator rocks and I was able to get SSH access to my hosting account with a simple phone call and for no additional charge; I’ve dealt with some other hosting providers that covet SSH access and treat it as an add-on.

From there, all you have to do is SSH into your hosting account you will be greeted with something that looks a lot like the a UNIX file system. Once in the file system, you are going to want to put your public SSH key into the remote .ssh directory; if that directory does not currently exist, simply create one.

Now navigate to the www directory for the site you are trying to add Git deployment to. Run the following command ‘git config receive.denyCurrentBranch ignore’. Then navigate to .git/hooks/post-recieve and add ‘GIT_WORK_TREE = ../ git checkout -f’.

On your local repo you will need to add a new remote pointing to your shared hosting directory and you may need to change the SSH port to 2222. Hope this helps someone.

Node.js VS Ruby on Rails When to Use What?

I have to admit it: I think both Node.js and Ruby on Rails are great.  I have been working with Rails for a while now and have a few Rails applications in production. I have been working on a project using Node.js for a few months now and, though the project is just something for me to scratch an itch and play with Node, I do see some benefits to working with Node.

Right of the batt Node is fast. Google’s V8 engine is the well…. engine that drives Node’s event driven magic and it is certainly the Lamborghini of JavaScript engines. To be clear, I like Rails, but in terms of speed Node beats Rails hands down. Again, I am sure that a bad Node code will still be slower than some super optimized Rails code written by a Rails Ninja, but still the point stands.

What Rails lacks in speed it makes up in bling baby! That’s right diamonds may be a girl’s best friend but gems are certainly a Rails developer’s. Currently, there is a huge and incredibly active gem development community that offers their code freely on sites like Github.com. Node does have NPM (Node Package Manager), but to date there are more gems than Node packages and their seems to be a bit more activity on the gem development side of things; again totally subjective, but there are some hard numbers on Github if you care to do the research; also, it is likely that the Node community will catch up, since the amount of interest and pace of development in the community is simply incredible.

There are a number of other points that could discussed here, but I feel the most important one is that Rails aims to be a full web development framework and Node is more akin to library. If you want a web dev framework that uses Node, consider Express.

Bottom line, I think that Rails is better suited for traditional web applications than Node. I base this mostly on efficiency of developing these sort of applications and the wide assortment of well tested gems that aide in web application development.  Node, however, has a very important place in the modern development landscape: powering backends for rich desktop and mobile applications. Again, Node’s speed and sheer ability to deal with a large number of concurrent connections in a small amount of memory makes this an ideal case for its use.

There you have it. It seems to come down to a trade between power against convenience. Thoughts? Rage filled hate? Find me on Google+ or Twitter. Also, please consider picking up Code Journal. Code Journal is the ideal way to collaborate with other developers using Github on your OS X workstation.

JavaScript is Not Assembly!

There is a growing idea on the web that JavaScript is somehow the assembly language of web. This is a horrible analogy for a number of reasons: it shows a misunderstanding of what assembly language is, implies that JavaScript is not a human readable language, and it  suggests that JavaScript is a far lower level language than it is.

According to Wikipedia, “An assembly language is a low-level programming language for computers, microprocessors,microcontrollers, and other programmable devices in which each statement corresponds to a single machine language instruction.” That doesn’t sound like JavaScript to me. Let’s keep reading and see what else Wikipedia has to say about assembly: “ An assembly language is specific to a certain computer architecture, in contrast to most high-level programming languages, which may be more portable.” Therefore for JavaScript to be considered an assembly language wouldn’t it have to target a specific computer architecture (such as i386 or ARM). Taking this to its logical conclusion, that would mean that for the JS == assembly relationship to work, you would also have to think of different browsers and JavaScript runtimes as different architectures. If that sounds crazy to you, that’s because it is. The analogy is broken just based on the definitions and essence of what assembly and JavaScript are respectively.

JavaScript gets messy. There is no doubt about it. Due to years of abuse by sloppy “devs” (who probably were more closely related to what today would be called an “Interactive Designer”) who didn’t treat it as a proper programming language but rather a little hack to get some fancy animation on a web-page. What does that have to do with assembly? Well, assembly is known to be very hard for humans to read; yes, I am fully aware that there are a number of hardcore individuals who can read and write assembly, but on the whole they are the exception not the rule. Guess what! JavaScript isn’t inherently hard to read. All this complaining about it being a tangled mess of crap is not the fault of the language but the fault of the dev and trying to force some analogous relationship with assembly onto it does not give you some sort of excuse for writing unmaintainable and hacky code.

Did I mention that assembly is low level  “down to the metal” sort of language? Guess what JavaScript isn’t? Ding ding! Well, done! JavaScript is not low level. While your C++ code is compiled to assembly and ran on your iPhone’s lovely ARM processor, your JavaScript is run in a JavaScript engine such as V8 in your web browser. Looks like JavaScript is running at something of a higher level.

My purpose here is not to beat up on the JavaScript detractors. The language (like all languages) could use some work, but adding an unneeded layer of abstraction over it is not going to bring the change the language needs. Standards bodies are slow, but you can “be the change you want to see” (Gandhi). Instead of abandoning it for some questionable layer of abstraction, use the great features in JavaScript, ignore the bad, and write maintainable code. If we all did this we’d find that over time the web would be a better place to work and JavaScript would be a better language to work in.  Not sure what the good parts are? Check out JavaScript the Good Parts. Got some feedback for me? Find me on Twitter or Google+. Also, check out my show Coder Radio on Jupiter Broadcasting. It is a weekly show on the art and business of software development.

Announcing Coder Radio

I am happy to announce that I am now co-hosting a show (Coder Radio)3 on software development with Chris Fisher on Jupiter Broadcasting. The show will air live every Monday at noon EST and be available for download shortly after.

I hope the show is a resource for sharing knowledge on both programming but also the business of independent software development. Please do feel free to contact me with suggestions of comments on the show.