The content on this site is my own and does not necessarily represent my employer’s positions, strategies or opinions.
- Today I installed Ubuntu 14.04 dual-boot on an Acer machine that came preinstalled with Microsoft Windows 8.0 but has been …
- While there are many second and third party sources for social media on the web, I find the primary ones …
- Today the World Wide Web Consortium (W3C) is celebrating its 20th anniversary as an organization. Luminaries and participants in the …
- Over the last several years, I’ve been deeply involved with IBM‘s Mobile efforts and now lead that technology area in …
- Continue reading
Today I installed good instructions available on the web. I installed Ubuntu from a USB stick.14.04 dual-boot on an Acer machine that came preinstalled with Windows 8.0 but has been upgraded to Windows 8.1. It’s slightly trickier to do this on modern machines, but there are
The installation was multi-step but straightforward. When I was done, however, it sure looked ugly on myTV monitor. First, the screen extended extended horizontally beyond the physical monitor screen, so the icons on the app launcher were chopped off. Second, the fonts appeared to be low resolution despite what I did to the Ubuntu Display settings.
After poking around for help on the web, I discovered that neither problem was an Ubuntu problem, but both were issues with the Samsung TV settings.
To change the Samsung TV settings, press Menu on the TV remote.
To adjust the screen size, go to Picture > Picture Options > Size. Then select either 16:9 or Screen Fit. One of them should fix your problem, probably the latter.
The second fix is unintuitive but has to do with how the TV monitor deals with input from a computer. I have my computer plugged into the HDMI1 port on the TV, which showed up as HDMI1/DVI in the screen source. In the TV menu options, go to Source List > Edit Name. Then go to the port where you have the computer HDMI cable plugged in, and change the name to PC. Presto, everything is beautiful.
While there are many second and third party sources for social media on the web, I find the primary ones most useful. That is, for example, I think that what YouTube says about its numbers is more valuable than comments from others who repeat other stats they heard, somewhere.
So here are a few links to those primary sources. I’ll add more when I find them.
Today the World Wide Web Consortium ( ) is celebrating its 20th anniversary as an organization. Luminaries and participants in the open standards effort will be gathering in Santa Clara, CA, this afternoon for a Future of the Web Symposium and then a Gala Dinner. I’m in New York, unfortunately, but I’ll be thinking of the times I spent on the standards, and the politics that changed the way we do technology today.
Here are some memories and thoughts.
- The earliest mention I can find of my involvement in the W3C is a note from Ron Whitney on July 11, 1996, stating that I had joined the new standards effort around the Mathematical Markup Language (MathML).
- The MathML group was composed of mathematicians, publishers, software developers, and some other unlikely people to be thrown together to produce “a web standard.” When MathML was eventually made an official Recommendation, we believed that it was the first standard from the W3C to use XML, other than XML itself. It’s still a cool standard, but its implementation in browsers is still sketchy nearly 20 years later. MathML is part of HTML5, so I hope it will finally get the first class treatment it deserves.
- Lauren Wood did a brilliant job of keeping the working group members, many with competing commercial interests, in line and directed toward the final standards product.
- Though I had done significant coding on a Netscape plugin, I often felt out of my depth compared with people from Netscape, , and other browser makers.
- I was amazed that the Netscape and Microsoft people spoke civilly to each other, given all the press about their competition and supposedly acrimonious relationship.
- Chris Wilson of Microsoft once said of a proposed new feature that it would break the browsing experience for millions of users. The scale of the web and how the standard would be used really struck me then, but at that point I had no problem breaking things in order to get to a better, more elegant solution.
- I first met Tim Berners-Lee in his office at MIT on a cold day. He was brilliant, focused, and all consumed with doing the right thing for the web. No other leader could have gotten us to where we are today, and that’s a very good thing.
- I also met Janet Daly at about the same time. She was also brilliant and committed to driving the right messages about the W3C to not just put it in a good light, but to change the world. The W3C and the standards world needed her at that right time and right place.
- As my position in changed from someone who created standards to someone who helped manage the creation of them on behalf of a company, so too did my relationship with the W3C. Let’s just say there was some tension regarding and the W3C and where new work was to be done. In all that time, however, W3C reps and employees were solidly professional and driven to do the right thing, despite what might benefit any particular commercial entity. I applaud them for that.
- Royalty-free licensing: kudos to Tim and the organization for raising the issue and forcing the rest of us to play along.
- I’m still not convinced about RDF and the whole Semantic Web thing, but then again, nobody asked me. :-)
So, finally, my heartiest congratulations to Tim and the W3C staff, past and present! It’s been an honor for IBM and me personally to have worked with you these twenty years.
Over the last several years, I’ve been deeply involved with‘s Mobile efforts and now lead that technology area in . In the last year we’ve held several hackathons and other events to get more and more people knowledgeable about how to create mobile apps. So with this experience and recent partnership engagements, let me offer five ways where I think people go wrong when creating an app.
- You don’t know who your user is or you are targeting too many kinds of users.
Mobile apps do not need to be all things to all people: you are allowed to create multiple apps that are fine-tuned to each user role. If a user asks “Why is this function here? It doesn’t apply to me.” you haven’t designed your app well. Different apps can use the same backend data but use it differently.
- You are not targeting one or two major functions or pain points.
Classic desktop and enterprise software have hundreds of features, but this does not work well in the form factors, user interfaces, and interaction patterns of mobile devices. Focus on one main task for your app that solves some specific problem or provides some great feature. As that gets refined and gains acceptance, you can add a small amount of new functionality as long as it does not detract from the main mission of the app. As in the first point above, you can have multiple apps and these can use the same backend data.
- Mobile is not essential to your solution.
Mobile devices are portable and have connectivity while you are away from wifi. While it may be nice to have a mobile version of a desktop or browser app, are you really taking advantage of the device’s features? Have you rethought the processes involved in accomplishing a task? While I would (and have) applied for a mortgage through a desktop browser, there is no way I would want to use the same process on a mobile device. Can your app offer significant usability improvements so that no one would want to use the non-mobile version?
- Mobile is an afterthought.
In this case, you have a really great idea for some system, undoubtedly doing amazing analytics with really important data. At the end of describing what you have, probably for an hour, you then say “and we’ll deliver it on a mobile device.” This makes you buzzword-compliant but not much more when it comes to creating a great app.
- Your app is not awesome.
You know when something is awesome and when it is not. If you start using an app and can’t wait to use it again, it is awesome. If you want to use it when you first wake up in the morning, it is awesome. If it becomes essential in your business or personal life, it is awesome. If you check it a dozen times a day, it might be awesome. If you use it once and forget you have it, it is not awesome. Use design thinking and get a good designer to help you. Practice lean principles to ensure that it gives people enough of what they really want or need.
I’ve been playing around with Swift, the new programming language from many languages and development environments since I started coding when I was 15, so I was anxious to see what Swift offered., for a few days and I’ve been quite happy with it. I’ve used
I’ve by no means used all the features yet, though I’ve read about most of them in Apple’s online language guide and reference. I’m using XCode 6 Beta 6, so I expect that some of the gotchas and incomplete implementations will be addressed in the next beta or the final version. Even after that I would expect the language to evolve further since most do.
Some of the things I like:
- Clean syntax
- Fast compilation, when it works (see below)
- Garbage collection
- A nice attempt at bringing the power of older languages like C++ into a more modern form that includes some features resembling those in
- A simple way to override syntactic operators like addition, negation, and multiplication.
My plan of attack here has been to take some C++ code I wrote 5 years ago and translate a subset of it to Swift. That way I can see how I would translate the ideas and structure into the new language. It’s been a good way to learn the language.
- Passing by reference and passing by copy are clearly distinguished with less syntax than C++.
- Because of the way it treats Unicode in a first class way, working with strings is more awkward than in many other languages. The need for Swift to coexist with Objective-C is also part of the reason, I believe.
- The automatic garbage collection reduces code size over my previous manual methods.
- I’m being more meticulous about when I can destructively change an object. (Almost never, and only close to where I create the object using specific init functions.)
- I’m looking forward to a larger collection of standardized collection types. Here I would expect a huge improvement over the Standard C++ Library.
- Once my core translated subset is complete and working well, I’ll look at using more of the idiomatic features of Swift and optimizing the code.
While working in the XCode editing environment, I hit a point where the computer CPU usage shot up to close to 100% for SourceKit, the underlying code base that handles all the editing, syntax checking, and code issue finding. Editing slowed to a crawl and sometimes I would get a message that SourceKit had crashed. Compilation took many minutes but the execution was correct.
I looked around the web, especially on StackOverflow, and found other mentions of the behavior but no great solutions and no problem situation that matched mine exactly. Eventually I went old school: I commented out most of my code and selectively added it back in until I could isolate the offending lines. Note that this was not a runtime error but an environmental problem while editing. That is: not my real problem.
If I had done something syntactically wrong, the editor or the compiler should have told me and not sucked up all the resources on my computer. If I was not doing something wrong, I should have seen no slow down.
Eventually I found that the offending code was
var s : Int = (u.bigits[j] * b + u.bigits[j-1] - q * v.bigits[n-1]) * b + u.bigits[j-2]
There is nothing wrong with the code except perhaps its complexity. I broke the statement into several simpler ones. By the way, I know I could have used “+=" but I wanted to be explicit and mirror the original statement.
var s : Int = -q * v.bigits[n-1]
s = s + u.bigits[j-1]
s = s + u.bigits[j] * b
s = s * b
s = s + u.bigits[j-2]
The problem went away. Editing and compilation speed returned to normal.
So the moral of this is that when working with betas of new languages, expect a few glitches and work around them. In the next release of XCode I’ll try my original statement and see if it has been fixed.
I’m looking forward to trying the new generics and constraints features. Though they look new to Swift, the ideas go back to at least the early 1990s.
Two other tidbits:
- If you know the type of an object, it does not hurt to be explicit in stating it. While it could be inferred, stating it makes the code more self-documenting.
- This release does not like spaces between unary prefix operators and their operands. That is, “- x” is flagged while “-x” is not. We’ll eventually see if this is a bug or a feature.
Yesterdayand made an important announcement about partnering to significantly growth the use of mobile via Apple devices in the enterprise. That is, the collaboration will significantly increase the functionality and value that mobile brings to people in their jobs.
Here are some of the most important links about this announcement.
- Press release
- Apple, IBM in massive enterprise hardware, software partnership (CNBC)
- Apple, IBM in Deal to Create Apps, Sell Phones (Wall Street Journal)
- Apple Joins With IBM on Business Software (New York Times)
- Apple Teams Up With IBM For Huge, Expansive Enterprise Push (techcrunch)
- Why the Apple-IBM deal matters (PCWorld)
- Apple and IBM Team Up to Push iOS in the Enterprise (re/code)
- Apple and IBM Kickstart Contextual Enterprise Mobility (Forbes opinion)
Having a collection of fewer high quality tools is better than having many cheap, inaccurate ones that won’t last long and may be dangerous.
When I was young, I couldn’t afford very good tools. I’m not talking about software here, I’m referring to things like power saws and kitchen pots. I bought them as I needed them, but they were never top end. Over time, I replaced them all.
The problem with cheap tools is that they often do not work very well and they don’t last very long. Other than that, they’re great! (grin) Inexpensive screwdrivers twist and lose the shape of their tips, for example.
Take the power saw. Cheaper models do not have the power and often the precision to do the job right. Yes, they may be better than a hand saw but your work may be sloppy and inaccurate. That hand saw? Cheaper models may not be made of high quality wood and the metal may be be too thin, so it will wobble when you make a cut. It will likely dull faster as well.
In the kitchen, inexpensive knives will also dull quickly and may end up being downright dangerous. With any tool, cheap or otherwise, you need to know how to use it safely so that it will at least not be ignorance that caused the nicked finger, knuckle, or worse.
So while it is nice to say “buy better, more expensive tools,” that doesn’t solve the problem of affordability. Borrowing tools may work, but better from a relative than a friend. Better yet is having a skilled relative with good tools to help you!
Plan your strategy of getting good tools over time, and spend more sooner on the really important things you need. Start by thinking about what you will be using frequently.
For household work, construction, and carpentry, spend extra as soon as you can on screwdrivers, pliers, and tape measures. You can do a lot with an accurate electric saber saw and a square. Get the best quality cordless drill and drill bits you can afford.
For cooking, begin with the knives. You don’t need many of them, just a few very good ones. Don’t splurge on measuring spoons and cups since inexpensive ones are often good enough. Get a good Dutch oven sooner rather than later. Favor fewer stick-free pots and pans with new, high quality coating rather than a set of cheap pots. Sets can be cheaper, but you can also build up your collection piece by great piece as you have the money.
As a final suggestion, tools often come in three price ranges: inexpensive, moderate, and very expensive. If you know nothing else, go for the moderately priced tools. That said, do your research.