thebhwgroup.com

How I Approach Inherited Code

Paul Francis — 2016-01-06T00:00:00+00:00

When I started at BHW, one of my first tasks was to take over an existing codebase that was originally written by one of our client’s in-house developers. Over the past 4 years, I have become an expert on reading this nearly incomprehensible code. This code is so bad that about once a month I will find a code snippet that I jokingly send around the office. I am truly amazed that this code has been used for over a decade and that its bits have helped process tens of millions of dollars over that period. The point of this story is not to complain about or make fun of this previous developer, but is to show that bad code exists and can run successful applications. {% include full-blog-image.html src="spaghetti.jpg" alt="A picture of a plate of spaghetti. Spaghetti code. Get it!?" %} Many developers see such code and hastly declare that it has to be rewritten. However, that is often unrealistic or impossible. The question then becomes, how do you approach bad code? This article will discuss my approach when working with existing code and will explore several key things I consider before writing a single `;`. ##Understand your Tech Stack Prior to looking for the exact lines of code you need to change, take a high-level look at the project. What languages are used? Is there a package manager? How is the code organized? What are the code's layers and interfaces? When working on a new project, one of the first things I do is find a simple page from the project to follow from webpage to database and back to webpage. Find the HTML, see where the styles are set, find where the request is received by the server, see how that server-side code accesses the database, and see how it is returned to the client. Then, see if the loaded page makes any additional server requests and follow those as well. As you get more familiar with the solution, try to see if the way code has been written has changed over time. This is important when working with code that has changed stewardship over a long period of time. The next point helps understand this further. ##Review Recent Commits {% include full-blog-image.html src="child_tracing.jpg" alt="A child tracing letters on paper. You gotta learn to code somewhere." %} Hopefully you have access to source control with historical commit messages. If this is not the case, I am very sorry, but please continue reading. Assuming you do have this access, take a look at some recent commits. Start with the messages to see what the intent of the change was. Then look to see what files they modified. Often, you will find a change that is similar to your task. Knowing what sort of files you will have to update to complete your task can be extremely helpful. Another thing to look for is code style. Code that is styled consistently is easier to read and understand. Take some time and see how the codebase looks and do your best to make your commits consistent. However, this does not mean you should write sloppy code if the existing code styling is poor or that you should restyle everything to match your preferences. This code could very well outlive you, so just leave it better than you found it. If you are luckier still and are able to speak with or have worked with the other developers, find commits from the developer you most respect and see how they work with this codebase. And of course, ASK QUESTIONS as needed. ##Understand your technical limitations. Time for a quick self-deprecating anecdote. When I first started working on the project I mentioned in the introduction, I was presented with a somewhat involved change. I did a bit of Googling and found a nice NuGet package that would be a big help. I added the package to the project, included the package in my file, and then got to coding. About a week later, it came time to deploy my changes to production. I transferred over my updated files, loaded up the website, and the site wouldn't load. 500s. I quickly revert the deployment and locate the error logs. It turns out my awesome NuGet package requires a newer version of .Net. More fun yet, that version of .Net can’t be installed on this particular “retro” server. The lesson learned is that you have to understand your compatibility limitations, including those in production. It is important to remember that your development machine (and even staging machine!) can be newer than the server the production app runs on. It is never safe to assume your environments will be the same. They almost never are! ##Read all the relevant code. {% include full-blog-image.html src="forest_through_trees.jpg" alt="A bunch of trees. References not seeing the forest through the trees." %} Unless you are making a simple copy or color change, I strongly recommend reading more than the lines you plan on editing. Understand the context of the file. I usually start by examining the included files and packages and then read the function headers of the file I plan on working in. At least a handful of times, I have skipped this step and written a function, only to realize another function already performed the same task. Another reason you want to review the code is to remove newly killed code. If you remove the usage of a class, function, or file, check to see if it is used elsewhere. If it is not, consider deleting it. Having dead code lessens the solutions maintainability. Furthermore, deleting code is significantly more satisfying than writing it. As long as you have source control in place, don’t be afraid to remove unused code. ##Deciding when to introduce new technologies. {% include full-blog-image.html src="bad_spoiler.jpg" alt="A new spoiler that looks very out of place on an old car" %} When working with older systems, it is very likely that a newer technology could be helpful when adding new features. But, there are many things you should consider before doing so. Here are some things to think about: ###How does this change affect the project’s learning curve? Some frameworks are quite difficult to ramp up on (such as the wonderful AngularJS). Can you imagine working on a site where every page had a different javascript framework in place? You would limit your reuse and drastically increase the time needed to train a new developer on the project. ###Is your new technology’s usage isolated? If the component you are updating is used widely in a project and is not properly isolated or interfaced, be wary of making a fundamental change. It might be the right thing to do but will likely require some regression testing and careful planning. The last thing you want to do is remove something only to find that you pulled a strand that is holding everything together. ###Will your new technology help make other changes easier? This is where understanding a project’s roadmap is invaluable. If you know you will have to build several new pages of a certain type and they would all be made better or easier with this new technology, then putting in a bit of extra effort to lay a new solid framework could be a great idea. ##Conclusion Every time you commit code, you are either improving or degrading a codebase. Bad code can be copied and extended. Or it can identified, contained, and with time, replaced. There are many things that can anchor a solution in terms of available technologies and frameworks, but even within that limiting context, code of wildly different qualities can be written. Take the time to understand the existing code and plan your approach. By following this guide, hopefully you are able to be a developer who leaves every codebase better than they found it.

Our Jekyll CMS migration from Drupal

Brett Burnett — 2015-11-16T00:00:00+00:00

##Why did we migrate from Drupal to Jekyll?

After fighting Drupal for two years we migrated to Jekyll

Four years ago we migrated our website and blog to Wordpress. I'll never forget the reaction when we announced the news to our team. **Silence, quickly followed by irritation, resentment, and eventually a lot of cynical jokes.** Two years after the move to Wordpress, we migrated to Drupal. There were many reasons why Drupal was a better fit for us, and this time I was sure the team would be lining up to build content. Unfortunately, the result was the same. Both attempts succeeded from a technical standpoint, but adoption and engagement never got off the ground. Our problem? **BHW doesn't align with the audience that CMS solutions target.** Our team is made up entirely of technical staff comfortable with HTML and Markdown. Our staff feels hindered by traditional CMS solutions. After two years on Drupal we migrated to [Jekyll](https://jekyllrb.com), a static site generator. This time the reaction has been different. {% include full-blog-image.html src="blogs/2015-11-16-jekyll-drupal-wordpress/cms.png" alt="Jekyll versus Drupal, Wordress, and Joomla for CMS" %} To be clear, Wordpress and Drupal are mature CMS systems that, when designed, deployed, and cared for properly, offer easy authoring solutions for almost anyone. **If your team isn't comfortable with HTML, text editors, and some basic source control, then a static site generator probably isn't for you.** While static site generators aren't poised to take over from traditional CMS solutions, their rising popularity and numbers can't be overlooked. Most businesses making a content authoring decision today will select a CMS, but what many don't consider is that you are committing to the platform and all it entails. It's too easy to believe the selection of an open source CMS is a low cost, low risk decision. Businesses incorrectly assume the "**free**" open source CMS should be easy to switch later, because after all it's "**free.**" Carefully consider what you're signing up for: - **Security** - **Patching** - **Upgrades** - **Training** Many of these efforts require good advice and guidance from consultants to be safe and effective. The cost of a bad decision is higher than you would expect, simply because CMS migrations are complicated and your valuable content is stored in a content database and deeply nested directories, spread into many fragments. **Putting your content back together can feel like an episode of a TV show with a team of people taping shredded documents together.** A small mistake can mean that the SEO your team has worked so hard to build is lost due to duplicate content penalties, broken links, or missing metadata. ##Security

75% of PHP sites have known vulnerabilities

Consider security for a moment. The popular open-source CMS systems are based on PHP and use many plug-ins for even the most basic website. There's been a lot of discussion lately about 75% of PHP sites having known vulnerabilities. New sites are less likely to be exposed to these issues, which leaves you to focus concern on the CMS software itself. While Drupal and Wordpress are carefully vetted for security flaws, vulnerabilities always slip through and require constant vigilance in the form of patching and updates. Most CMS best practices recommend using as few plug-ins as possible to reduce the surface area for attacks. **Plug-ins are usually written by much smaller teams, are patched less frequently, and in most CMS systems, are the principal entry point for attacks.** Even if you invest the time to stay ahead of these issues, now you have to deal with human concerns like weak password complexity, shared passwords, etc. An issue in any one of these areas opens your site to attack. Compare this experience to a Jekyll generated static site. Jekyll only runs on a workstation and produces static files. Your server only runs a web server, a config file, and hosts your static files. Instead of serving dynamic content from PHP-based CMS systems and their plug-ins, you serve static files through [Nginx](https://www.nginx.com) or [Apache](https://httpd.apache.org), two of the most **hardened and thoroughly tested web servers on the planet.** Supporting Nginx or Apache couldn't be easier, with most linux distributions automatically updating these two packages for vulnerabilities. The overhead and worry of running a PHP CMS is reduced to nearly zero. **What about recovery?** If your CMS has been running awhile, be prepared to face issues installing exactly the version of plug-ins and software you need, then patching up your vulnerability. If your PHP CMS was hacked, you are probably facing a server reinstall and database restore, including a file system restore for your images and other assets. Without a recent backup you will lose content and data. Don't underestimate the time and complexity of a rebuild, and if you're concerned, ask your team or vendor to perform a restore test to make sure you're prepared in the event of an attack. Be ready to watch their face fall as they consider the effort. Even if you're lucky and have a snapshot backup to restore, you still have to bring it up and hope you can find the vulnerability and patch it before getting hacked again. Recovery on Jekyll can be as simple as: - **Provision a new VM** - **Install Nginx** - **Deploy your files** Unlike a PHP CMS, there's no chance for content or data loss in Jekyll because your static files are deployed after being built on your local workstation. With distributed and hosted source control, your site will be safe even if you lose access to your workstation. Simply find another computer, pull down your source, install jekyll (it's a one-line command line install), and build your website. ##Performance

Performance is another advantage Jekyll holds over a PHP CMS. A search of Google for Drupal or Wordpress performance will display many recommendations of plug-ins and proxy servers, two of the most popular being W3TotalCache and Varnish. **Even after using these solutions, carefully tuning our configuration, and upgrading our server, we still couldn't reliably deliver our expected performance.** A quick search will show the same performance challenges mentioned online. Caching and proxy systems are used in an effort to overcome the poor performance exhibited by Drupal or Wordpress. Both underlying CMS systems are very chatty, running many queries to render a single page. Plug-ins make this worse by running their own queries too. Viewing a typical page can generate hundreds of queries to the content database. Caching is a great way to get around this problem, but has its own downsides too. Caching strategies vary, but you often need a larger server with more RAM to cache your website. Edits to single pages might be a quick cache update, but site-wide changes mean you have to completely rebuild the entire cache. On our Drupal site, rebuilding the entire cache took almost 10 minutes, and the site was basically unusable while this occurred. Proxy systems like varnish may even cache based on the HTTP User Agent, resulting in multiple copies of the website for different devices and browsers. **We took the approach of pre-caching our site, but if we simply let the site render pages that missed the cache, we would see page loads over four seconds.** Our move to Jekyll allowed us to retire all this infrastructure and simply use Nginx for serving static files, a task that it excels at. It's so fast in fact that we were able to reduce the size of our VM server several times and save on hosting costs, all while proving better performance than before! ##Configuration Management

finding what to change and having confidence in its outcome can be a real challenge

CMS systems bury their configuration in multiple settings pages. Once you add modules to the mix with their own setup, you can easily have a situation where your configuration is stored in over ten different screens. Couple that with the reality that your custom pages and blog content probably have their own settings and controls for their metadata and SEO information. When you need to make a configuration change, finding what to change and having confidence in its outcome can be a real challenge. Compare this to Jekyll's approach. Configuration is stored in one of two places, the _config.yml file for system-wide concerns, or at the top of the page or post's individual file in the ["front matter"](http://jekyllrb.com/docs/frontmatter), a YAML section listing a simple collection of name-value pairs useful to the page. Jekyll's approach is a welcome change to your average Drupal or Wordpress site. It's very empowering to review your configuration information all in one place while having the ease of editing using text editor tools authoring, search and replace, etc. ###Content Versioning In a traditional CMS system you may have content versioning (with a plug-in), but that feature seldom extends to versioning system configuration information and templates. Usually you would create a database backup before configuration changes, naming the backup something appropriate to reference later if needed. The backup is opaque. **There's no way to know exactly what was changed, you simply have a before-and-after version of the system state.** Jekyll's flat file approach is exactly the same, but fundamentally different in how it is applied. Unlike database backups, flat files are easily compared, and differences are easy to understand using command line tools or GUI products like ["Beyond Compare"](http://www.scootersoftware.com). Jekyll may accomplish the same end result of storing a before-and-after picture of the configuration state, but its done in a much more approachable fashion that provides amazing utility. When you couple this approach with source control, you now have a visual record of the changes, a note about the reason, and an audit of who performed the change and when. **Jekyll's configuration management is so superior to a CMS that it's one of the main reasons we moved our website and blog from a database backed CMS.** This one feature gives you easy fallback, branching support for testing new ideas, a contextual audit trail, comments, and more. The power of this approach to change management extends even into the content itself, allowing pages and posts to be edited in the same powerful comparison context. Don't underestimate the value of this key difference between these platforms. At BHW, this one feature was the main reason we even researched flat file CMS systems to begin with. Drupal and Wordpress have some plug-ins that promise visions of a similar approach, but many of these plug-ins have drawbacks and are frequently incompatible with other plug-ins you might select for your website. ##Cost I started the article mentioning that many businesses underestimate the cost of a traditional open-source CMS. Free software doesn't translate to having a "free" website. Even if a business has a handle on the upfront cost, very few understand the upkeep cost. Long-term cost breaks down into several categories: - **Hosting** - **Maintenance** - **Content Authoring** Hosting cost can vary dramatically, but most analysis agrees that hosting Drupal or Wordpress can be expensive. There's no question it's more expensive than hosting a static site generated by Jekyll. Sites like github pages can now host Jekyll static sites for free. Not every Jekyll site can make use of github pages though, which prevent the installation of certain plug-ins. The difference in cost could be insignificant for smaller websites, but if your business has enough viewers and content, you will probably pay significantly more for hosting Drupal or Wordpress because you will be forced to pay for performance in the form of larger servers for caching.

Free software doesn't translate to having a "free" website.

Maintenance is likely the cost most businesses underestimate. **Ignoring maintenance is the central reason most websites gets hacked.** Constant vigilance is required to monitor for vulnerabilities and install updates or patches. Most of the time the update or patch can be installed easily; however, some updates require code or configuration changes. Plug-ins might not port a patch to the version your website uses, forcing you to upgrade to a new version of the plug-in. These code changes and forced upgrade events occur more than you would think, and they're always unexpected. Usually you end up working in a staging environment to test the update before deploying to production. In order to accurately test, it's important to mirror production as closely as possible, meaning synchronizing production content into staging. This can be a time consuming effort on its own, but the truth is that few businesses do this. **Most simply install to production and "hope for the best," then react if something goes wrong.** Some likely consider it an educated gamble that saves the cost of running a second environment at the expense of some unexpected urgent website work if something goes wrong. Once your open source CMS has been running awhile, you'll eventually have to make a major version upgrade, like going from Drupal 6 to 7 or 8. These are extremely challenging and time-consuming events, and ignoring them puts you at risk since support for older versions of the base CMS solution fades quickly as new major versions are released. ##Authoring Removing any barriers during content authoring was the biggest factor in exciting our team. Few things can stop adoption faster than a poor experience in the authoring tools. Once staff start contributing, the next challenge is how to help them make their content compelling and engaging. Again, if the tools get in the way, our team is less likely to contribute. In both cases we found that authoring from the familiar environment of a text editor like Sublime was far superior when compared to a browser-based CMS tool. A third barrier is the infrastructure requirements for authoring, data connection, logins, VPN, etc. We wanted to enable our team to author content wherever they were without jumping through hoops. **A benefit we never expected from Jekyll is that it allows completely off-line authoring.** Because Jekyll ships with an integrated web server for the authoring workstation, our staff can author even if they are offline without a data connection. The final engagement hurdle to clear for our team was confidence. CMS systems can present steep learning curves and the specter of a mistake in configuration can mean that your content is ineffective. Jekyll's publishing and compositing system is so simple that it doesn't trigger the same anxiety that a complex CMS evokes. ##Flexibility

it's hard to imagine a more portable format for our content than Jekyll

The last consideration is content flexibility. How easy is it to move your content to another authoring solution? We feel that Jekyll's static file approach is more "future-proof" than using a content database. When we first performed our migration from Drupal to Jekyll, we tried to use a script to pull content. Because we used plug-ins for metadata and images, the tool was unable to pull all of our content. We had to write more scripts on our own, dig around in the database, and use Ruby code to piece things back together. Even after the code efforts, we still had to do a manual scrub of many files. Now that we're on Jekyll, if we ever decide to switch to a different CMS, it's difficult to imagine a more portable format for our content than Jekyll's static files. Each file contains all the content and configuration settings needed for rendering on our website. This is far more useful than piecing together content from a database. ##Conclusion One thing we didn't discuss in this article is the initial website development. At BHW we seldom develop websites from a template, preferring to build responsive websites best tailored to designer's visions using the appropriate tool for each job. We routinely build integrations and websites on systems like Drupal and Wordpress for clients, and from our experience there's no question that Jekyll is easier, which translates into cheaper. If your business can accommodate the higher technical bar that Jekyll imposes, it's undoubtedly a better value than a traditional CMS. There are countless successful websites running on Wordpress and Drupal. I'm happy to say that our website is no longer one of them.

Austin Web Development

Paul Francis — 2014-10-20T00:00:00+00:00

##Austin Web Development - Our Story This article will focus on what it means to be an Austin web development company and how that affects the way we work, what it’s like to work with us, and our overall approach to web development. Just to mix things up, I will use various Austin businesses and attractions to introduce my points. {% include full-blog-image.html src="Austin_Skyline_at_Dusk.jpg" alt="Austin Web Development - skyline" caption="By Randall Chancellor (Flickr)" %} ##Austin Web Development - Our Approach {% include full-blog-image.html src="chilantro-food.jpg" alt="Austin Web Development - Chilantro" %} {% include full-blog-image.html src="mighty-cone.jpg" alt="Austin Web Development - Chilantro" %} {% include full-blog-image.html src="gordoughs-donut_opt.jpg" alt="Austin Web Development - Gordoughs" %} As anyone who has spent even a weekend in Austin knows, food trucks are delicious, convenient, and cheaper than traditional sit-down restaurants. Places like Chi'Lantro, Mighty Cone, and Gourdough's do not trade quality for convenience, they are simply more mobile. Similarly, we attempt to remove unnecessary costs when developing websites or mobile apps for our clients. Part of how we do this is by not having internal middle-managers or project managers. Instead, we only hire developers who are capable of interacting with clients through every aspect of the development process. This is similar to how at food trucks, you order food directly from the chef. This decreases the likelihood that your order is misunderstood and also assures that you have more accurate and direct information about what you will be eating. Eliminating misunderstandings that are often introduced by adding additional layers between the developer and product-owner significantly reduces the risk of a project going off-track and almost always results in a better product. ##Austin Web Development - Our Developers {% include full-blog-image.html src="jwj-acl-fest-09.jpg" alt="Austin Web Development - People" caption="photoblog.statesman.com" %} Austin is the self-proclaimed “live music capitol of the world.” That is a pretty bold claim, but as an avid music fan and consistent festival attendee, I can attest that Austin is a consistent stop for almost every artist. Festivals like ACL, SXSW, and Fun Fun Fun Fest attract established and up-and-coming artists alike. Likewise, Austin is a current hotbed for technology. Tech companies and developers are both moving to Austin in droves. We make every effort to attract and hire the best developers and being based in Austin is a huge advantage for us. We have little trouble convincing potential hires from other cities to work for us. Several say things similar to, “I am only looking for jobs in Austin.” As mentioned in the previous section, having excellent developers is crucial to our business. Being an Austin web development company is a definite advantage and helps assure our potential clients that we have top-of-the-line developers and do not have to hire second-tier talent due to being located in an undesirable location. ##Austin Web Development - Our Culture I am quite sick of the phrase "keep Austin weird" and am glad to be seeing less of it lately. Actually, I see and hear the phrase more often in other Texas cities. But, the heart of this idea (for me at least) is that Austin offers something for everyone. Are you into live comedy? Check out The Fallout Theatre. Enjoy free concerts in the middle of a large park? Blues on the Green is the place to be. Are you a beer-snob who wants to learn more about brewing? Head over to the Live Oak Brewing Company and make sure to try the Primus while you are there. No matter what you are into, Austin has likely already embraced it. In fact, it will probably expose you to entirely new interests. We maintain a similar approach to web development. Just as each Austinite needs different things from their city, as an Austin Web Development company we understand that each client and project is unique. Therefore, BHW matches the correct technologies to each project, rather than relying on a default "cookie-cutter" list of frameworks and languages. What this means to our clients is that we have experience solving all sorts of problems and are familiar with both emerging and traditional technologies. We bring this wealth of knowledge and experience to each project. ##Austin Web Development - Our Success & Future {% include full-blog-image.html src="ADC_LOGO_RGB.png" alt="Austin Web Development - Our Future" %} Whenever an out-of-towner visits, I make sure we make a stop at the Draft House. Whether it is the great food, the replacing of traditional commercials with film specific pre-screening clips, or extremely serious appreciation of film and film-viewing, it is hard to think of a single thing that better represents Austin. Like many other successful companies with their roots in Austin, the Draft House has expanded to several other states, but have stayed true to their uniquely Austin approach. In a similar manner, although we are an Austin web development company, we have recently opened a Dallas office and have customers that are located all over the US. Just like the Draft House identified and fulfills a nation-wide desire for a different style of movie theatre, BHW has built it’s business around a unique direct customer-to-developer relationship that is more cost effective than our competitors and leads to better quality web applications. We firmly believe and hope this article has shown that as an Austin web development company, The BHW Group, is ready to meet this need.

Do you need an expert in web development? With a team of web development specialists covering a wide range of skill sets and backgrounds, The BHW Group is prepared to help your company make the transformations needed to remain competitive in today’s high-tech marketplace.

Web development in Austin

Brett Burnett — 2014-10-07T00:00:00+00:00

##Nine years of Web Development in Austin 2015 marks BHW's ninth year of web development in Austin. It's fun for us to chat with old clients and hear that they're still using systems we built for them nine years ago. Recently during a college recruiting trip we actually had to register for a career fair and post jobs in a system that we built for a client in 2002. We're so happy to see projects like these stand the test of time, because nine years in web development might as well be an eternity. Sure, you can build web applications today with the same technology used nine years ago, but the cutting edge of web development has turned itself over several times and looks nothing like it did. To attract the best talent BHW has also changed, allowing us to keep up with the pace of web development. Our lovely city of Austin would almost be unrecognizable to a visitor returning after nine years, and our web development firm in Austin is no different. ![Web development in Austin](/sites/default/images/austin-jobs.jpg) Published by SeeSaw - September 11, 2014 ##Mobile development If you follow our blog you'll see how closely we monitor trends in open source web development, and for the last four years mobile development as well. During these years the web has gone from a desktop-only culture to [mobile-first development](http://en.wikipedia.org/wiki/Responsive_web_design). Every new project we start begins with a mobile development strategy and understands how applications function on the small screen as well as the desktop. Mobile development is changing even faster than web development and shows no signs of slowing. As the hardware vendors race for mobile dominance, users benefit from better devices and better user experiences via the web or mobile applications. Techniques in mobile development that were the norm two years ago are now viewed as obsolete and even forgotten. ##Open source development Throughout this time open source software (OSS) has pushed the envelope and driven much of the change. It's amazing to think that OSS runs the operating systems for over 50% of mobile devices, and these devices outnumber desktops 3 to 1. So much innovation happens in the OSS community that the toolchain vendors are always playing catchup. At BHW we've gone from being a Microsoft-first shop, to more of a 50/50 split. When we start work for a new client who doesn't have a technology stack constraint, we now recommend OSS as our first selection. Even our new projects starting on the Microsoft stack are heavily influenced by open source techniques. We're excited about open source projects, especially the rise of dynamic, functional, and asynchronous programming. Web development is poised to change again. ##Application development Nothing has survived the test of time in web development, including hardware. During the last nine years the cost of servers and hosting have fallen to the point of becoming commodities. The exciting economics of hosting have given rise to the cloud and innovative application deployment strategies like [platform-as-a-service](http://en.wikipedia.org/wiki/Platform_as_a_service) (PaaS) and application hosting vendors like Heroku and later Azure. It's now easier than ever before to enter the web development world and host a custom application in the cloud, removing the need for licensing, upfront hardware investments, and installation. Expensive heavy-iron server environments with high-availability and redundancy have fallen out of favor as the rise of cheap, inexpensive multi-node environments running sharding technologies, map reduce, and [Hadoop](http://hadoop.apache.org) have taken over. ##The future of web development What does the future hold? It's impossible to say. The mobile development and web development worlds continue to converge with open source solutions like [Apache Cordova](http://cordova.apache.org) leading the way. The mobile-first design paradigm and responsive web design techniques mean that more and more developers will be seriously considering [native versus hybrid](https://thebhwgroup.com/blog/2014/09/mobile-app-development-complete-approach) development and trying to justify the cost of native approaches. In the web development space, mobile will continue to dominate the trends. We've been concerned for the last two years with responding to larger and larger screens on mobile with desktop going retina and soon to be 4k. We now have to wonder where the wearables trend and [Apple Watch](https://www.apple.com/watch) will take us. It's likely web development will adapt to the stamp-sized screen and move toward solutions more akin to push notifications with one-touch responses rather than traditional web pages with point and click navigation. Nine years ago no one could have predicted we'd be here. The future for web development and mobile development is as bright as ever, if even more clouded, but we'll continue to navigate the paths for our clients so they can capture the value that technology can offer.