Tag: Web development

Re-Infected by Smalltalk

I seem to be afflicted with a chronic, recurring condition, a sort of living nightmare in which I imagine myself a programmer. I’ve experienced this numerous times over the past several decades, but it appeared to be finally cured in my retirement as I focused my life more on spiritual matters.

But recently, I decided that I wanted to develop a couple of Web and mobile applications in support of my spiritual teaching as well as for the nonprofit Job One for Humanity volunteer work that I’m doing. Without much of a commitment to actually doing something, I started poking around in the world of mobile application and web development.

By a chain of circumstances I can only be described as being dragged down a dark rabbit hole, I encountered a language which I had explored previously as a possible development language and environment. I’m referring to the Smalltalk-inspired Amber language. In the three or so years I have been away from Amber, it appears to have undergone considerable growth and gained in popularity. More importantly, it appeared to have overcome most if not all of the packaging, delivery, and performance issues inherent in traditional Smalltalk.

Ever since I first discovered it something like 15 or 20 years ago, I have loved Smalltalk. It is my favorite, widely-used programming language by a lot. (If I omit the qualifier, “widely-used”, then that honor goes to LiveCode.)

So I was excited to encounter a vastly improved Amber product which is a tool that generates high-quality JavaScript code from working Amber applications. Even though I’m not a systems-level guy, I set out in an effort to install Amber on my Mac with complete confidence it would be a positive experience.

Man, was I wrong!

As it now stands, Amber does not apparently have any easy way to install on any platform. It involves so many dependencies and requires so much command console typing (which for me is far more painful than programming) that I was tempted several times to give up. But I persevered. However, I kept encountering roadblocks I could not decipher or understand, and when I sought help in the Amber community — or in one of the communities supporting one of the dependency modules — I got very little response and nothing definitive that actually worked.

As a result, after three days of mucking about with it, I gave up.

But that is not the end of the story. In the course of investigating Amber, I discovered that a newer dialect of Squeak Smalltalk — which, over recent years, has become the Gold Standard of free Smalltalk environments — was also capable of spitting out web applications using generated HTML, CSS, and JavaScript. This relative newcomer is called Pharo.

Not only does Pharo have a single-button install, its documentation is really outstanding. There are a number of free e-books available, several of them authored or co-authored by the original developers of the language, and they have a wonderful tutorial as well as an online video course spread over several weeks of in-depth training.

So now I’m off, once again infected by Smalltalk, learning this new dialect and the robust environment in which development takes place, for the moment at least happy as a clam. I truly hope the Amber team gets its act together on the installation side, because I’d love to explore it as well, but for now I’m sitting sale to master Pharo and make these new application ideas a reality.

P.S. to Laurence. You knew this would happen, didn’t you?

 

WordPress vs. Drupal vs. Joomla! Graphically

I encountered a thread on LinkedIn today that referenced this infographic comparing WordPress, Drupal and Joomla! and found several pieces of data in the graphic to be intriguing and a couple downright surprising.

Most Interesting

  • Joomla! has overtaken Drupal in a number of statistical categories indicating popularity.
  • Drupal is at least twice as expensive to set up and customize as either of its rivals.
  • Average monthly maintenance costs for Drupal are 3-6 times that of the other tools.
  • Both WordPress and Drupal are updated more often than Drupal but not at dissimilar rates between them.

Most Surprising

  • Joomla! has gone through six major revisions in its eight years compared to seven for Drupal in 12 years and only three for WordPress in 10 years.
  • Drupal and Joomla draw nearly the same number of visitors to their main sites each month, just under 30,000. WordPress? 50 million!
  • Joomla! is in use on almost twice as many sites in the top million sites as Drupal, but both are under 3% compared to WordPress’ 14.3%.

 

Safari Tops Mobile Web Browser Competition With Nearly 62% Share

According to the latest statistics from Net Applications, the Safari browser from Apple retains its top position among mobile web browsers, maintaining a 61.79% share of that market.

safarilogoSafari has led this competition from the beginning, due in large part, no doubt, to the dominance of Apple’s iPhone in the mobile marketplace. Coming in second is Google’s Android browser,  which racks up just under 22% of the market. Nobody else is really close.

Interestingly, Google Chrome, a relatively recent entry, almost doubled its share from the last study, but still limps across the finish line with 2.43% of the market.

The primary implication, of course, is that Web developers can safely target the Safari crowd, which includes several other browsers all built on the WebKit technology platform. This, in turn, presents yet another argument in favor of writing HTML5 Web sites and applications in preference to native applications, since it all but guarantees that such products will run on most if not all major smartphones and tablets.

WP Headache Remedied: WP Super Cache “Hidden Feature” at Work

wplogoI have been frustrated and largely unproductive for the past few days working on three WordPress projects and having the same issue with all of them. I won’t go into the gory details but I think sharing the Reader’s Digest Condensed version may help those who stumble on this post.

If you’re working on a WordPress site and you find that changes you make aren’t being reflected when you view the site, no matter how many times you refresh, reload, turn off caching, empty caches, disable caching plugins, and make awful faces at your computer, you need to know this.

If you’re using the most widely recommended and used cache plugin for Word Press, WP Super Cache, and you’ve deactivated it at some point in your debugging, it is still most likely the culprit!

Why?

Because it turns out that when you deactivate the plugin, it does not clear the page cache it has created. And since you’ve deactivated it, it is no longer able to delete any expired pages. Catch-22.

Chances are you have not spent much if any time in the very complicated Settings for WP Super Cache. But there’s a huge amount of stuff you can control. Someone really ought to write an eBook on it. (Hmmmmm)

So if you have this problem of changes not showing up, and you have been using WP Super Cache, then follow these directions:

  1. Re-activate the plugin if you’ve deactivated it.
  2. Go into its Settings (conveniently linked from its entry on the Plugins Page)
  3. At the top of the first page, check the checkbox that turns caching off. (This one’s probably not necessary if you’re deactivating anyway, but I’ve become paranoid by now.)
  4. Look for a button labeled “Delete Cache.” Click that sucker.

Now you can deactivate the plugin or delete it.

For me, at least, problem solved.

 

Intel Grabs appMobi; First Signs are Pretty Ugly

Intel Corp. has acquired the widely respected AppMobi platform for HTML5 Web app development, but its first public-facing foray into the field leaves a lot to be desired.

The cross-platform (aka “write once, deploy anywhere”) development tools are supposed to produce identical results across browsers. But Intel’s Web page for signing up for the new site shows up radically different in Firefox and Chrome. You can see the differences by clicking on the image thumbnails below.

In Firefox, the Intel AppMobi page is garbage.

In Firefox, the Intel AppMobi page is garbage.

In Chrome, the Intel AppMobi page displays and works correctly.

In Chrome, the Intel AppMobi page displays and works correctly.

 

 

 

 

Clearly, Intel doesn’t get it.

‘Nuff said.

Beyond Responsive Design to Reactive Design

The latest rage sweeping the Web design world is responsive design. This is a set of design principles and techniques which allow a design to shift dynamically in response to the environment in which the user is viewing the site. At its core, it means that views resize gracefully.

Most modern Web designers seem to favor designing first for the small screen of a smartphone and then expanding the designs out to the full-sized browser, perhaps with an intermediate stop at a pad-sized view.

This is very cool stuff and I heartily applaud it.

Today as I read this column on TechCrunch by well-known designer Jay Jamison, it occurred to me that one problem with responsive design is that as the design effectively "shrinks" from full-sized to phone-sized presentation, the designer of necessity makes decisions about what content and links and imagery will appear on the opening screen, which is the hard-line equivalent of "above the fold." Speaking from experience, that's not always an obvious or easy call. Balancing the user's interests against the publisher's needs and desires is never easy and when you compress the real estate within which you can make those trade-offs, you make those choices more difficult.

What if we let the user make those decisions rather than the designer? Furthermore, what if we allowed the user decision to be inferred from behavior on (and perhaps even off) the site? In other words, rather than having the user experience merely adjust visually to the differing screen size, we make dynamic decisions about what to display based on what user behavior has previously told us about his or her preference on the site?

I propose to call this new approach reactive design because the design reacts to user behaviors and preferences, expressed and implied, in deciding what and how to present its information.

Any thoughts?

Jimdo Emerges as My New Web Tool of Choice

After spending more time than was probably good for me, I've slogged through a couple dozen tools for creating Web sites that met two specific criteria I'd developed and emerged out the other side deciding to pin my hopes on Jimdo. I thought someone else might benefit from my analysis, so I'm sharing it here. (Actually, this is just a very quick summary of my reasoning, but it hits the highlights.)

The two criteria I had were based in large part on issues I kept running into while using WordPress as my tool of choice for the past couple of years. I had decided that if I was going to find a new tool, it would have to have these two basic characteristics to make the first cut:

  1. Minimizing the need for me to know or use PHP and/or master relatively complex file hierarchies to do even fairly simple stuff.
  2. Allowing my clients to edit their sites without having to understand much, if anything, about how they were structured or how to use a sometimes bewildering Dashboard.
I started out by asking a question on LinkedIn. The thread that emerged was very helpful and I've struck up longer conversations with several of the participants outside the thread. I also made direct inquiries of a number of colleagues. I also found a great site that specializes in evaluating Web Site creation tools and spent a good bit of time there.

Filtering all that content down based on my two key criteria, I narrowed the initial list to (in no particular order):

  • Basekit
  • Jimdo
  • concrete5
  • Squarespace
  • Interspire Web Publisher
  • Weebly
  • Yola
I actually built a sample site — or part one a site — in all of those tools except Interspire and Yola, the former because even though it looked pretty decent, it didn't fully meet my second criterion and its price ($395) combined with a good bit of Nettlebut about a slow and non-responsive development cycle and inadequate support didn't feel right, and the latter because it proved to be either too inflexible or non-intuitive.

Of the remaining five tools, I gradually eliminated the following for the reasons indicated:

concrete5 because: (a) although the tool is free and even open source, almost every add-on for it were priced higher than I thought was fair and would have made it a costly investment; (b) the self-hosted solution wasn't available as a one-click install on any of my hosting services even though to of them were advertised as being good hosts to use. (It turned out that in one case the problem wasn't concrete5 but rather the hosting service.)

Squarespace because the templates it offers are pretty simple and plain,which would be fine except that even minor customization requires using CSS and HTML and because simple tasks like centering images required me to set CSS properties for padding and border rather than just clicking a "center" button.

Weebly because, of all things, it does not support sidebars or any other notion of shared content across pages outside the header and footer. I was incredulous, assuming I was just missing something, but an email exchange with support confirmed it. Copy-paste maintenance of content I want on multiple pages is not going to cut it for me or my clients.

Basekit because I ended up having to make a trade-off decision between it and Jimdo. Basekit is a great tool. But it lacks a blog component, which was essential to one of my three new clients for whom I was doing this evaluation. Jimdo has a blog but doesn't support customized forms. I decided it would be easier to use something like Wufoo to create and embed a custom form into a site than to kludge inclusion of another blogging tool without losing the seamless functionality I was seeking. But I could have gone either way. I'm hoping the Jimdo guys will get to the custom form stuff at some point soon.

So I'm off to dive into Jimdo by building the first and simplest of the three new projects. I expect you'll hear from me more on this subject here over time.

Yahoo Clouds Web App Development With “Cocktails”

It's not bad enough that we developers have to make tough choices between native-platform app development and HTML5-based Web app development, now Yahoo comes along with a binge drink with which to confuse us even further.

The fading search giant has cobbled together a fairly ugly looking combination of technologies in what it calls "Cocktails". This guest column at CNET provides a glossing-over of what Cocktails is, without trying to be sufficiently specific to allow any real examination. The most salient fact we can derive from the puff piece is that Cocktails will combine HTTP, HTML5, Cascading Style Sheets, and JavaScript into some sort of development platform that they'd like us to think is really new. But wait a second. What does "HTML5" mean? While the label gets bandied about fairly frivolously, most developers who've taken a few minutes to look into it know that HTML5 is the next major development in HTML5 that will enable the design of richer application-style interfaces and interactions including multimedia.

Anyone developing Web apps using the loosely defined HTML5 technology suite would surely be using HTML, CSS and JavaScript, so what exactly is new in Cocktails?

In the CNET piece, Yahoo's Bruno Fernandez-Ruiz,  the technical lead for Cocktails, says, without, apparently, any sense of irony, "Our platform combines basic ingredients that exist on the Web already, including HTTP and HTML, Cascading Style Sheets (CSS) for formatting and animation effects, and JavaScript for more sophisticated programming (both on a Web server and on individual devices)."

So, what exactly is new here again? 

If you go beyond today's CNET piece, you can find out that the major differentiator claimed for Cocktails is the use of server-side JavaScript (SSJS). Hardly new. Check out this piece from SitePoint that's almost exactly three years old predicting SSJS would become as popular and widespread as PHP. That hasn't apparently happened yet but SSJS is hardly new. At best, then, it appears Cocktails is an incremental improvement on lots of platform-agnostic Web app development platforms that allows the developer to take better advantage of SSJS. 

Yahoo has released two cocktails so far: Mojito, yet another environment-agnostic JavaScript Web application framework, and Yahoo! Manhattan, a hosted platform for Mojito-based applications. 

Useful, yes. Exciting? World-changing? Don't think so.

Occupy Flash? Huh?

Ran across the Occupy Flash site tonight. The site is trying to mount a national or global effort to get users to uninstall Adobe Flash Player from their (primarily) desktop machines. The idea being that as long as the player has its present ubiquity, developers will continue to throw resources at it as an app platform despite the availability, as part  of the rapidly dominating HTML5 standard, of open source approaches to multimedia apps.

Seems like kind of a weird idea to me. There's not a lot of HTML5 multimedia stuff out there yet; a great many sites are sticking to Flash while many are making a slow transition to the new standard. The move is premature. In a year or possibly less, such an undertaking will actually make sense without damaging the average user experience too much.

But it's a nice idea.