It occurred to me that if Microsoft sold an iPod Touch-like device, but with Metro interface and apps, I’d buy one. Metro is slick. It would be really nice to use it on a small, affordable (sort of) touch screen.
But then I thought some more… Microsoft would, of course, only allow syncing via a proprietary, non-great music store app. And that app would transcode all my mp3s into wma. After which, I would be locked in the Microsoft trunk.
So… nevermind.
We programmers love our unix commands. Which is why so many embrace MacOS: every command shell is a unix shell. Sadly, that’s not true on Windows.
The traditional work-around is Cygwin. Which is excellent. But it feels unnatural, like running a VM window with another OS.
This week, I discovered GnuWin, a project that ports the unix command set to windows. There is a slick installer here.
After installing the GnuWin commands, and adding the bin directory to my path, I can now fire off unix commands from a normal windows command console, or from PowerShell.
Life is good.
The first few iPhones (and, later, Android phones) all had a screen width of 320 pixels. This prompted web developers everywhere to design mobile sites that were exactly 320 pixels wide.
When Apple introduced the retina display, they doubled the screen width to 640 pixels. Current Android phones go higher than that even. When you view a screen optimized for 320 pixels on a retina iPhone, you could see something like this:
Except that you don’t, of course, most of the time. And that is because of a magic setting called “viewport”. It works like this:
<meta name="viewport" content="width=device-width, initial-scale=1">
The “width” value above can actually be a number of pixels, like “640″. But if you use the special value “device-width”, which almost every mobile page does, crazy adjustments are made. What am I talking about? Read on!
According to Edward Cant:
With the advent of high pixel density displays the pixel itself is now a relative unit.
According to the CSS 2.1 Specification:
Pixel units are relative to the resolution of the viewing device, i.e., most often a computer display. If the pixel density of the output device is very different from that of a typical computer display, the user agent should rescale pixel values.
So, a ‘CSS pixel’ indicates one point on the virtual pixel grid to which our CSS design aligns. This either directly matches the actual device pixel grid on which our content is rendered or it is intelligently scaled.
This has led to the definition of a ‘Density-independent pixel (dip)’. (Android Developers)
A virtual pixel unit that applications can use in defining their UI, to express layout dimensions or position in a density-independent way.
iPhone4 was not the first to employ virtual pixels although other implementations often had less convenient scaling factors. 1 virtual pixel could equal 1.5 physical pixels and so on.
A detailed summary of the ‘Pixel is not a pixel’ situation is available on quirksmode.
If that confuses you, let me simplify: the “pixels” we specify in CSS are not actually hardware screen pixels. They are an abstract grid laid on top of the screen. How wide is that abstract grid? Ah! Now we get to the heart of the matter.
By specifying width=”device-width”, you are asking the browser to apply a scaling factor to its screen pixels. One css pixel occupies one or more screen pixels. How many more? This value is called the css pixel ratio. There is a good list of devices and their css pixel ratios on wikipedia.
If you study that list, you will discover that screen width / css pixel ratio = 320 in most cases. For some Android phones, it comes to 360, a little more breathing room. Bottom line, by specifying width=”device-width”, you transform the browser window into what is effectively a 320 (or so) pixel screen. And now your site that is optimized for 320 pixels looks like this on any phone:
Neat! So as you design mobile sites, you may assume that all phones are 320 pixels wide.
But of course…
The world has moved on. We now use media queries to provide responsive designs across various pixel widths. And we don’t need to punish people with good phones by forcing narrow windows on them. For the modern mobile site, it is better, I think, to omit the viewport width setting, and rely instead on responsive techniques.
Oh boy!
Tech news has been dull of late. But this evening, I opened Google Reader, and these three stories jumped out at me:
Ina Fried and John Paczkowski report:
In the highly-anticipated court ruling, a court said Google’s Motorola Mobility unit is entitled to about $1.8 million a year from Microsoft for certain patents. Motorola had been seeking in excess of $4 billion in the case, which centered around patents related to the the H.264 video standard and the 802.11 wireless standard.
In making its determination, the court noted that there are some 92 different entities with patents essential to 802.11 networking. If each of them got the 1.15 percent to 1.73 percent royalty that Motorola wanted, the cost of just wireless networking alone would exceed the price of the Xbox Microsoft was using it in.
What I love about this is: The court is arguing that there are so darn many potential patent claims that all claimants will have to accept a token payment. Perhaps this is the practical solution to patent trolling. Make it not worth attorney fees to pursue it.
Betaworks has bought Instapaper, the read-it-later service built and run by Marco Arment. The widely read developer said on his blog today that he wanted to focus on other projects.
This startles me, for two reasons:
If it is not open-source, and (at least potentially) self-hosted, you cannot rely on it.
Facebook has acquired Parse, a company that helps developers create apps across different platforms by providing a toolset and back-end support, the company announced on Thursday.
I’ve been keeping a lazy eye on the backend-as-a-service (BAAS) companies. It’s a great idea, but it suffers the same challenge as a new bank: you may love the service and fees, but you really crave predictability and security. How can you build on a BAAS that may not be there next year?
Parse and Stackmob, to my mind, are the current leaders. Parse sold out. What does that say about the fate of their peers?
Mindful of the point I made about Instapaper, above, Meteor and Derby are open source, potentially self-hosted alternatives.
Data points:
That’s the context. Here is what I think it all means:
Why would you pay $800 for an iPad with a lot of local storage? Because you want to use your iPad to replace your laptop. The “tablet-replaces-laptop” movement is well underway. Apple is just acknowledging it. And capitalizing on it. And sanctifying it.
The surprising success of the new, low-cost Chromebooks by Samsung and Acer are more proof that the masses don’t care about Windows software anymore. If they can use the web, email, and do office work, they are good.
Given that, do you think that Dell will hang in the consumer PC market long term, after they go private? I don’t. I think they will refocus on enterprise sales, support, and consulting. Inevitably, this means they will get heavily involved in linux. They will eventually adopt a Redhat-style model: custom distro with paid support. Oracle is already doing this, btw.
As Samsung is learning, post-PC companies need to own their own OS. Samsung will look to gain stewardship of Meego, much as Google has stewardship of Android.
That leaves four companies in the consumer PC business: HP, Acer, Asus, and Lenovo (sort of). Lenovo is already halfway down Dell’s path, selling mostly to enterprises. HP has considered divesting the PC division. This topic will keep coming up.
In the short term, the last four PC builders will try to thread the needle, with a mix of Windows, Android, and Chrome machines. It’s a difficult task, though. Two of them will fail in some way (sold, merged, shut down).
And Microsoft? They have already split their OS across three lines: server, prosumer, consumer:
So where does that leave programmers like me? Same place as the last few years. Focus on the web. It works everywhere.
I tried to set up a sub-site on an existing WordPress 3.5 site. The admin let me create the site, but when I tried to visit the sub-site’s dashboard, I got a “too many redirects” error from the browser.
I googled for hours. I tried many, many things. In the end, this particular version of .htaccess worked for me. YMMV. Good luck.
RewriteEngine On RewriteBase / RewriteRule ^index\.php$ - [L]
# add a trailing slash to /wp-admin RewriteRule ^([_0-9a-zA-Z-]+/)?wp-admin$ $1wp-admin/ [R=301,L]
RewriteCond %{REQUEST_FILENAME} -f [OR]
RewriteCond %{REQUEST_FILENAME} -d
RewriteRule ^ - [L]
RewriteRule ^([_0-9a-zA-Z-]+/)?(wp-(content|admin|includes).*) /$2 [L]
RewriteRule ^([_0-9a-zA-Z-]+/)?(.*\.php)$ /$2 [L]
RewriteRule . index.php [L]
There used to be a lot of posts in the blogoshpere arguing for pure html functionality. According to the pure-ists, a site was supposed to work fine with just html, and nothing else. The rest (css + javascript) was supposed to “progressively enhance” the site.
I don’t see those posts anymore. I think they were killed off by jQuery. Seriously. I think a lot of designer-turned-htmlers were freaked out at the prospect of learning javascript. Javascript is, after all, a Turing-complete programming language. You may as well have asked them to learn Java.
jQuery hides all the parts of javascript that scare people. I am embedded among Java programmers, and even they feel good about jQuery. (Dear Java friends: you can learn javascript, you just choose not too. I get it.)
A big tip-off that javascript was secretly the problem: those earlier posts never inveighed against CSS. They seemed to assume, somehow, that CSS was not part of the problem.
Much as jQuery made javascript approachable to the masses, CSS pre-processors like LESS and SASS will make CSS fun. But we’re not there yet. It will be another three years, I think.
When I say that CSS sux, I am not talking about the flaws in the language. Every language has flaws. I refer, instead, to the current notion that true web developers must master all the intricacies of CSS. That includes browser-specific directives, plus the mathematically-inclined properties of gradients and transitions. And they must never, ever, use a table.
LESS and SASS have already covered the obvious blemishes in CSS. I think they will eventually go farther, as jQuery did for javascript libraries, and make complicated things easy.
I am forced to work with Java again, and I find that a sound language is now strained to the breaking point. Java, itself, is still fine, I guess. I’m suspicious of annotations and generics, but whatever. The problem is that working programmers have to gird themselves with a cluster of java technologies: ant, maven, spring, jboss, eclipse, hibernate, ehcache, junit, and more. It does not surprise me that when recent college graduates found startups, they choose Ruby or PHP instead. (And now, javascript on node.js.)
Java has peered over this cliff before. That’s when the POJO movement, Java’s punk rock moment, won back mindshare for a kinder, simpler java. It could happen again.
Obviously, there are a lot of high-volume sites, and enterprise back-ends, that rely on Java. And they aren’t going to change. But that just makes Java a legacy language. There were lots of COBOL jobs through the 1990s. But we knew which way the wind was blowing.
Also, Java is the official (and only) language of Android. That should keep it relevant for a long time.
Now that I’ve trolled my java friends, let me throw them a bone: I’m also worried about the fate of my beloved javascript. Javascript could rise and become the dominant language of the next 20 years. Or it could be gone in 10.
There are 4 dominant browsers, and they will never collectively agree to embed a new language runtime. So javascript will forever remain the common denominator of web development.
Native apps for devices are selling well these days. But I have to believe that developers are unhappy about: 30% tax on sales, lack of ubiquity, and potential gating. They will constantly strive to move users to web apps, which can only be written in javascript.
Node.js is a super attractive environment. Server-side development will increasingly flock there, which means javascript everywhere.
Javascript is evolving. The Ecmascript standards effort is adding language features. And there is vigorous work on libraries and frameworks.
Coffeescript, Typescript, Dart, and others prove that: 1) there is a demand for alternatives; and 2) “compiling” to javascript may actually work. I am unpleasantly surprised at how popular Coffeescript has become in the startup community. I don’t think it’s poised for a breakout of its own. But I acknowledge that it demonstrates a deep current of dissatisfaction inside the javascript community’s cognoscenti.
Ecmascript evolution is proving to be both a blessing, and a curse. There are a number of proposed or planned language “enhancements” that, IMHO, make javascript even less approachable. This is not going to help adoption of the language.
It’s possible, though increasingly unlikely, that another language will emerge. Dart seems to be hitting the right marks: classical inheritance, optional type declaration, compiles to javascript, has own runtime. But I don’t see any uptake.
A decade ago, I was a hardcore TCL programmer, looking for the next language to hitch my wagon to. In the end, I split the difference: javascript and PHP. It looks like those choices are going to play out in the long haul.
Actionscript, JavaFX, Python, Ruby, and Scala all gave me a scare a some point. But nothing ever crossed the chasm. I ride with the herd, and my herd is still strong.
I’m not sure web developers know how under attack they are from mobile devices and ‘native.’
Me too.
It’s an open secret that mobile ad revenue is not keeping pace with desktop revenue. Everyone with a content site is freaking out about this, including my corporate masters. But the problem extends beyond the executive suites: front-line web developers need to embrace the new platform.
All those Macbook Pros and Macbook Airs are also part of the problem. Because they don’t have touch screens. Sure, hip web developers have smart phones and tablets. But they still live inside of non-touch laptops. The future is a touchscreen world, even if Apple hasn’t discovered it yet.
Over in the mobile world, users are convinced that “native” apps are the way to go. For political reasons, that will probably always be true. (Apple and Google are not in a hurry to surrender the revenue from their app stores.) But web developers know better. We know that HTML 5 + javascript is all we need to provide awesome mobile apps. We know that native wrappers like PhoneGap and Titanium are all we need to reach into the device’s api.
Still, there are many fat and happy web developers, like me, who work for companies that are raking in revenue from desktop browsers. My brothers, I am here to tell you: we are doomed. Do the right thing: start a side project that is mobile-only. Learn about PhoneGap and it’s rivals. Bone-up on mobile frameworks. Investigate the booming back-end-as-a-service companies that are serving the mobile dev community.
Whether or not our desktop sites survive, mobile and tablet are the future. That is where the big money and glamour jobs will be in 5 years.
One of my New Year’s Resolutions was to make a new site every month. Since it is still October, I am 10 sites behind my goal. I guess I’ll roll that one over into next year.
The other day, I was hoping to make some progress on site #1. Although I embraced the joys of maintenance programming this year, I was also dimly aware that things have progressed in the PHP world. I just didn’t know how much. When I tried to spin up a new site with the latest tech, I was confronted with new stuff like:
And that’s just to start! It turns out my old friend Zend Framework has been radically changed. Zend has been travelling down an unpleasant road for a while now. Version 2 confirms the choice. Time for us to part ways.
Luckily, the PHP community’s “let a thousand frameworks bloom” approach comes to the rescue. A quick Google search of “php framework mongo db” surfaced the Lithium Framework. (NoSQL is the obvious choice of the cool kids, and Mongo DB is the obvious winner of the NoSQL wars. Honorable Mention to Redis.)
So… my next project will be in Lithium, on PHP 5.4, and Mongo DB. Wish me luck.
Thomas Kinkade died last weekend. I was on vacation, so I learned of it days later. Here are some articles that I found helpful in understanding Kinkade:
I have mixed feeling about Kinkade and his work. I was first introduced to his art 20 years ago. My uncle gave me a tear-off calendar featuring his work. This was back before the internet, when it was hard to learn about people. The blurb on the calendar called him “the painter of light.” He claimed to be a Christian. Implied in that statement is this:
I really liked the art, and kept the pages as I tore them off. I kept them for years.
When Kinkade Galleries began to appear, I was rooting for the guy. I thought the galleries would mostly sell prints, so they only needed a small inventory of actual paintings. I assumed that he was an industrious Protestant who beavered away, knocking off copies of his paintings to fill those galleries. I was wrong.
What I eventually learned is that Kinkade used his purported Christianity to gain people’s trust, selling them Kinkade Gallery franchises (which mostly lost money), and paintings that were knocked off by minimum-wage art students.
So, for the last decade, I’ve written Kinkade off as yet-another-fallen-hero. I still like his art. I just can’t get behind the man, or line his pocket with any money. For me (but obviously not for his family), his death is not untimely at all. His story ended. Two or three more decades would not make it better.
Rest in peace, Thomas Kinkade. I will continue to secretly enjoy your art.
Recent Comments