Here’s a good discussion hosted by Google Developers about the pros and cons of developing for web browsers vs. creating (mobile) native apps: Read More
A year ago I wrote about how the involvement of various media companies in open source software was worth paying attention to. It still is, but it is equally interesting to see commercial vendors back successful OSS that, on the surface, looks like it may be competing with their paid products. One such project is Adobe’s Brackets [home | Github], an excellent free code editor that has been going through rapid iterations and impressive adoption by developers – both those working on the software itself, its many extensions, and the broader population of people simply using it. Read More
If your head is spinning from the deluge of tech product announcements that make you feel like you’re always trying to catch up, no matter how close you stick to technology developments – breathe deeply, you’re not alone. Here are a few pointers to frame how to think about the costs and benefits of various types of web hosting. In short, there is no silver bullet, and like most things it’s all about cost-benefit trade-offs. Yes, “the cloud” is becoming better and new solutions seem to crop up like mushrooms after rain, but you can spend days researching vendors that in the end, are pretty close to each other and won’t impact much how your business is doing. Some questions to ask yourself: Read More
More and more websites are made by assembling back-end libraries and front-end components provided by third parties, rather than built in house. Web developers typically spend less time coding than integrating code from others, among other tasks. Face it, most organizations don’t have the resources to compete with the collective work put into a WordPress or Bootstrap, and even if they do, in most cases it wouldn’t be a good use of said resources.
Think of it as a supply chain, like how car “manufacturers” are actually assembling components more than they are “building” products from raw materials. They focus their actual component manufacturing on a few critical parts like engines – and even then often in collaboration with competitors – but they get parts from a whole ecosystem of suppliers. Aircraft makers are not even in the business of making engines! How we go about making websites is going through a rapid and exciting phase of maturation. To the “build or buy” question, the answer is increasingly “buy”, though money is not even necessarily involved. Read More
The last couple of years has seen a burst of experimentation in the news world to go beyond the print-inherited definition and delivery of news stories/articles/entries. That is genuinely great, but it remains hard, even for leading organizations with vast resources, to scale beyond one-offs. This is due to a mix of interlocked factors, including: CMS constraints coming from strict database schemas and content types, workflow friction, culture, and front-end technology that’s still very much a work in progress.
I plan to cover this more at length in due time, but in the meantime here’s a quick conversation with Elise Hu from NPR and NYT’s Jacob Harris on this very topic: Read More
The explosion in the quantity and quality of both commercial APIs and open source projects is a huge enabler for digital start-ups and small businesses. Instead of painfully rolling your own version of, say, sending email newsletters or displaying a media gallery, in many cases “there’s an app for that.” However, behind the numbers, the very uneven quality of the documentation made available with said APIs, plugins, and packages, is a serious impediment to fully realizing the productivity gains promised by these vibrant ecosystems. (Wow this sounds way too much like an enterprise software whitepaper!)
Typically documentation takes shortcuts by implying bits of knowledge that the reader may not have, skipping necessary steps, leaving out important nuances, or providing incomplete and obtuse examples. These issues are compounded because of today’s development by integration more than pure coding. I’ve been thinking about how this could be alleviated. Read More
Like many people developing with WordPress, I used to use XAMPP to run a Linux/Apache/MySQL stack under Windows. This beats developing directly off a remote server by a long stretch (in case anybody still does that), but it turns out to be quite a hassle as you wrestle with / vs \ in paths and other discrepancies between the Unix and Windows worlds. Developing in an environment as close to production as possible ends up being a much better choice. Popular free tools to do so are:
- VirtualBox to run other operating systems within your own
- Vagrant to manage development environments within VirtualBox
- Puphpet, a wizard-like interface to help set up Vagrant through Puppet automation scripts. Phansible does the same but using Ansible.
Yes, these work somewhat like Russian dolls, as modern web development has a severe case of tools to set up tools to set up tools. It can get a little crazy at times, so you want to find the sweet spot where you gain efficiency without becoming a slave to your toolset (which is supposed to save you time in the first place). Getting this up and running is a big enabler for continuous integration, and why you would want to think and develop that way is the topic of a separate entry.
In this post I’ll share some practical details to contribute a little back to the open source community and not just consume its benefits passively. The end result is a fully functional Unix environment serving a WordPress website locally on a Windows PC, across a whole local network.
This entry is written from the perspective of “Unix as a foreign language” from a Windows native. It does assume that you have read the basics about VirtualBox and Vagrant, and focuses on common roadblocks that I’ve encountered along the way. As always, the key to learning a whole new way of doing things is to break it down in small digestible chunks. Read More
I’ve put together lists of teams and people working at the intersection of news publishing, data, visualization, and online/mobile/software development to get a better sense of who talks the talk and who walks the walk. There’s a strong UK presence, while some organizations are missing that you’d expect might want to show up.
This would deserve some analysis (anyone up to datamine Open Source Report Card?), maybe later.
1. Github repositories from news orgs Read More
I haven’t posted on this blog for a long time, mostly because we’ve kept ourselves quite busy hunting for, then buying and renovating a house in Concón, Chile. After 5 months of remodeling, we finally moved in last month and we’re very happy to have made that choice which satisfies both our heads – we’re convinced it’s a great investment over the long run – and heart – outstanding direct view on the ocean, lots of space, our kids love it. There’s easily two or three years of additional work ahead to get our dream home out of it (and home office – did I mention we’re across the street from the Pacific ocean?) but we’re starting to be nicely settled already.
On the web publishing tech front, we’ve been working with ExpressionEngine for a bit more than a year. We like it for the most part, but still have several unresolved issues: Read More
The fine people at EllisLab have a quite interesting post on how they see feature requests. Generally speaking, I like their voice. Unlike many web 2.0 companies, they’re not delivering the usual pandering bullshit: “it’s all about you the users and the comm-you-nih-tee.” Yeah right, like we can’t figure out the part about UGC economies of scale in your pitch to VCs.
EllisLab is saying, look we do appreciate your feedback, but it’s our job to maintain the product’s sense of purpose, stay the course and deliver. It’s refreshing, it’s honest, and it’s the right thing to do. You need the courage to say no to a lot of requests, whether externally or within a company with your internal users by the way. You also need to execute on some of those ideas, or people will just see the whole thing as an exercise in futility. Maintaining a transparent dialog about why feature requests make or don’t make the cut is key. Easier said than done as sometimes you’d rather just sit down and ship product.
Salesforce is doing a great job with its IdeaExchange (here’s their blog about it). There are ASPs (Oops, sorry for the 90’s wording, surely it’s more hip to say SaaS) such as BrightIdea too, and of course, a blog dedicated to idea management systems (what topic doesn’t have its blog this days, carrot juice fetishism maybe?). If you can educate internal and external users about trade-offs and cost/benefit decision making, I think given enough scale (i.e. you need the manpower to handle the firehose) these systems have real potential.