Posts from the ‘Development’ Category
Slashdot: “But love it or hate it, the one thing a modern developer cannot do is ignore JavaScript. It is slowly but surely eating your world.”
Truer words were never spoken.
Yesterday I was lamenting the lack of good choice for coding in the browser. I know, I know, I gripe too much about it. I can hear folks now “Just shut your pie hole and learn JavaScript, like everyone else.” That is good advice, I should learn JavaScript, but I digress.
The mere mention of it started a conversation on Twitter, which lead me to start thinking about a weblog post, which lead me to a search for “CLI in the browser” or something like that, which landed this great post by Miguel de Icaza.
“ECMA CLI would have given the web both strongly typed and loosely typed programming languages. It would have given developers a choice between performance and scriptability. A programming language choice (use the right tool for the right job) and would have in general made web pages faster just by moving performance sensitive code to strongly typed languages.”
This is what I’m after. Choice and closer to native performance. JavaScript could be one of the supported languages, and should be for that matter, but in the end it would be really great to have a language agnostic runtime.
I’d compare the state of coding in the browser to coding 20+ years ago. At that time everyone was using C because it was the most portable way to get your code on other OS’es. I find it a bit depressing browsers haven’t moved past JavaScript. Can you imagine only being able to code in C on your favorite platform? Of course not, that’s preposterous.
It will be interesting to watch browsers mature into a layer that completely replaces the OS for services. Until then, we’ll have to make due with what we have.
Here’s the Twitter conversation that lead to this post (sorry, the Twitter embed code only grabbed the last bit of the conversation, not sure how to get it all.):
@notrazawa @kepford I do, but we certainly don’t have to agree. JavaScript is a starting point for an immature environment. It’ll change.
— Rob Fahrni (@Fahrni) May 14, 2013
Well, it happened, Apple sold 5000 WWDC tickets in 90-seconds. Amazing. Of course it wasn’t all roses for everyone. Some people saw errors after thinking they got a ticket, others instantly got the “Sorry, we’re sold out message.” That’s not the story.
The story, at least to me, is the few developers who believe they are somehow more deserving a ticket than others. That’s a bunch of hogwash. No one developer is more deserving of a ticket than any other. This is how things should work. First come, first served. If you didn’t score a ticket, try again next year. I was able to attend WWDC 2011, Steve Jobs final keynote. I understand why developers really want to attend. It’s a chance for us to hear about new and exciting things before anyone else. We also get to hang out with friends and talk to other developers. That’s probably the most important part of the week; hanging out with friends.
I’ve read too many gripes that say it was their chance to meet others and hang out, and now that opportunity is gone. Why is it gone? Come to California that week and go to an alternative event if it really is that important to you. What’s stopping you? Nothing but you. I get why it’s important to connect with other developers and have dinner and a few beers. It’s a time to unwind, let your hair down, as they say. In 2011 I was able to hang out with a longtime friend. We hadn’t seen each other for ten years. It was a great time.
Alternative
Yes, there is a great alternative to WWDC that same week. You can attend AltWWDC, and it’s free!
If you missed getting a ticket and believe its important to get together with fellow Apple Developers you have a place to go.
Hopefully I’ll be able to attend at least one day, maybe two. If I do make it, I hope to make some new friends.
Maybe I’ll see you there?
Mike Jurewitz: “I have watched too many developers over the years focus on the wrong things in their products. Some endlessly add feature upon feature and take so long to ship that their users have long since moved on. Others endlessly rework a feature in pursuit of some nebulous technical excellence that isn’t necessary and whose pursuit certainly doesn’t pay the bills. And others find themselves constantly moving the target they’re trying to hit, redefining the features, UI, or problem-space of their product in a continual reaction to the world around them. These are easy traps to fall into. After all, we’re all human and most of us are making it up as we go.”
Good advice. Maybe people don’t teach this anymore? You can’t have a 2.0 without ever having a 1.0, right. Iterate, iterate, iterate, but ship between those iterations. Some people have to find the perfect solution for everything, or they waste their time rewriting code that works because they don’t like the style, or believe their way is better. There are, of course, good reasons for rewriting code, but the reasons I just mentioned aren’t among them.
I’m guilty of doing this stuff myself, when I was younger. What I’d end up with is code the way I liked it, but offered the same functionality. No net gain. I’ve learned not to do this. I now move forward and tweak things as needed for the next release. Yes, it must be solid and usable, but it doesn’t have to be perfect in every way.
I’m not the greatest developer in the world. I’m slow and my code has never been the prettiest in the world, but it’s in use by well over 10 million people worldwide, and that’s a pretty darned good feeling.
So, my advice to you is, find a nice minimum set of functionality, make it usable, make it solid, and ship it. That will let you move forward. It will afford you the opportunity to create a 2.0.
Deputy Joseph: “So if you were one of those who got turned away by the old JavaScript, I urge you to give the new boy a chance. Try doing some server programming in NodeJS or some database operations in MongoDB. Perhaps you may not get smitten, but I trust that it would trigger an epiphany nonetheless.”
Even though JavaScript is an ugly, nasty, hack, it’s probably the most widely used scripting language in the world. Browser support is now ubiquitous and it’s the only way to script the browser as far as I’m aware? I think it’s fair to say JavaScript is the duct tape of the Internet. It’s not pretty, but it’ll do in a pinch.
I’d be interested to see how NodeJS scales on a web scale project, you know, something like Twitter, Facebook, or Instagram. Is it good enough for that? It’s interpreted so I don’t see why it couldn’t be used for that. Folks love PHP, Python, and Ruby for web back ends and they’re interpreted.
I’ve had my eye of CoffeeScript for a while. It removes some of the JavaScript suck and the folks behind it are serious about its continued quality and success. The only downside? In the end it has to emit JavaScript. The only reason that’s bad is it could emit something incorrect, but hey, compilers have to emit code and we trust them, right?
People believe JavaScript is the future of development. I hope not. I hope it motivates people to make something better.
In the meantime we have to embrace the suck.
Dave Winer tweeted something today that got me thinking, so instead of tweeting back and forth with him about it I thought I’d jot my thoughts here. Twitter is pretty horrible for discussions.
This guy thinks Dropbox is the wrong idea, but users like it, guess they didn’t get the memo.2yc.r2.ly
— Dave Winer ☮ (@davewiner) February 9, 2013
In response I pointed out that Dropbox and iCloud are different because Dropbox is a file syncing service and iCloud goes beyond that. If you’re a Mac or iOS developer you can sync portions of files to iCloud along with your application settings. Apple created this as an extension of their ecosystem. As a developer you can have automagic syncing for your applications, if you choose.
Of course I misunderstood Dave’s point. His concern is lock in.
@fahrni — it is the worst idea if you’ve committed yourself to interop and fighting vendor lock-in.
— Dave Winer ☮ (@davewiner) February 9, 2013
Ah, now I see what he’s referring to. Apple has created a walled garden for applications built on their platform. It’s absolutely true. Another concern of Dave’s is the inability of iCloud to share your files outside of applications.
@fahrni — the files stored in dropbox can be opened by any app.
— Dave Winer ☮ (@davewiner) February 9, 2013
Once again, Dave is absolutely correct. There is no way to get at your content in iCloud if you’re not using an app that implements iCloud API’s. Oh, there is support for Windows, did you know that?
Here’s the deal. With iCloud Apple allows you to open your document, stored in iCloud, in your local application, make changes, and those changes can/will be sync’d back to your other devices. Here’s the difference as I see it. Dropbox is an extension of the filesystem on my local computer, iCloud is an extension of my application. Subtle, yes.
I’m having a difficult time getting to the difference because it is so subtle. Imagine if you have a Pages document open on your Mac and on your iOS device. You’re making changes on the Mac and you walk away. Those changes will get pushed to your iOS devices without saving the document. As far as I know you cannot do this with Dropbox. Dropbox will sync an entire file, not portions of a file.
Minor difference, but a difference none the less.
How about this. Dropbox allows me to see all my content via the web and my local filesystem has a copy of the documents. It’s absolutely perfect in that way. What about editing? Can you go to Dropbox.com, log in, and edit a binary Visio drawing? No, you cannot. With iCloud we get this feature via apps. Again, it’s avery subtle difference, but it’s something Apple is very fond of.
I’d imagine once Apple can solve these types of issues we’ll see a more open iCloud, until then, if you’d like a great file syncing solution Dropbox is a better choice than iCloud. If you’re after great integration iCloud may be your best bet, although some applications have done a great job using Dropbox as their syncing solution.
In the end syncing of files across multiple computers is a very difficult problem to solve and Apple is just beginning to address the problem. Dropbox has created a very elegant full file syncing solution. Both are useful.
Oh, one more question. I almost forgot to ask this. If Apples’ iCloud is a lock in, which I will not argue, how is being tied to Dropbox not lock in? I would consider it lock in. To me what’s freed us from lock in are open protocols, like HTML, or RSS. They are part of the fabric of the internet and completely open. I can modify HTML with any application that can read, write, and modify simple text. Definitely no lock in. If Dropbox created an open protocol for syncing of files, that could be implemented by anyone, and their client application, as well as anyone else’s, could communicate with any server that implemented that protocol, I’d say it wasn’t lock in.
A stretch? Maybe. But we are, after all, talking about subtle differences.
Craig Hockenberry: “What happened next though, surprised us in a very good way. David started using Xcode.”
I love stuff like this. It’s neat to see how folks approach development inside their shop. Most of the post is not surprising. Their approach is the same as every development shop I’ve ever worked in. Divide and conquer where it makes sense. He didn’t go into their unit test process, but does mention he was able to test his code with his own test application. This is important and mostly overlooked by most developers.
Like I said, it’s mostly basic stuff and common practice, until you come to the line I pasted above. THEY GOT A DESIGNER TO USE XCODE! That’s amazing and it looks like it allowed them to move their application forward without interrupting the developer or frustrating the designer because the developer was too busy to be fussed with a tweak to the UI.
When I’m coding I like to get the basics in place and skin later. It’s easy to do, why not give it a bit of time before you go off and do it, right? Well, if you can get a designer to do the work, why not? It’s a brilliant idea and UIAppearance seems to make it even easier to deal with this kind of stuff. I’m looking forward to using it some day.
Craig also mentions another thing I really love about The Iconfactory.
“We are well aware that people are going to complain about missing features: push notifications and streaming are obvious examples. But so are trends, and video support, and in-line photos, and… well none of that matters. We believe in building opinionated software.“
I love that. They managed to build a client that is perfectly suited to how I use Twitter and they did it by building it how they would use it.
The Iconfactory is definitely one of those shops I’d give my left arm to work for. True story.
Steve Streza: “Today I shipped the first alpha of Apparchy, which turns Twitter’s official iOS apps into App.net clients. You sign up for a free account on apparchy.net, add your app.net account, and then log into the Twitter app with your Apparchy username and password. Then, the Twitter app will start loading data from app.net through the Apparchy API.”
This is a nifty trick. A very appropriate hack for a hackathon. Steve has made Twitter’s own client post to App.net. It’s not as difficult as one might think because of a legacy feature remaining in the official Twitter for iOS, and I believe Twitter for Mac, clients.
It’s interesting to note that Twitter has allowed Twitter for Mac to die. If this works with the Mac client it just breathed new life into an otherwise dead piece of software. Well done.
The big question is, when will Twitter shut this down? One week, two? It won’t take long before we see a new drop of Twitter for iOS in the App Store with this feature removed.
It’ll be interesting to see if they ship another release of Twitter for Mac just to turn this off.
Until then, enjoy!
P.S. – Does this mean Twitter’s official client is breaking the Display Requirements?
Andrey Butov: “The people who really seem to benefit from using the abstraction layers are web developers who aren’t comfortable with native code (C/C++/Obj-C/Java), but who are very strong in Javascript/HTML5/CSS. I’m not in that camp, so having to skip a native-code implementation, in favor of Javascript, would actually be a disadvantage for me, rather than a benefit.”
Andrey does a great job of sharing some of the reasons it’s best to choose a native platform over something like Titanium.
I guess we all go to our comfort zone when it comes to life, and that holds true for software developers as well. I prefer to use the platform tools, so I have a history of writing in C, C++, and now Objective-C. Yes, it’s painful to learn a new platform, but I think it’s worth it.
UPDATE (8/26/2012, 2:20PM)
Branch: A Blow To HTML5: “Facebook has now largely moved away from HTML5 in favor of native Objective-C code with their new iOS apps. And the results speak for themselves. Facebook had been one of the companies that most vocal in their support of HTML5 as the future of everything. The apps suffered as a result. And now they’re changing their tune. Is HTML5 still just not ready for prime time? At least on mobile?”
HTML5+JavaScript is never going to be as fast as a native application. I think it depends on the goals for you application. If you’re ok with a lowest common denominator experience, a web site will do just fine. If you need a rich, interactive, experience you may want to create a native application, especially on mobile. When I use my desktop I don’t mind visiting website based services as much. I think it comes down to screen real estate and I can easily switch away from the site and dow something else, while it loads.
I guess the bottom like is, I believe native is a better choice, at least for the foreseeable future.
In the wake of the new Twitter 1.1 API changes announcement I thought I’d focus my attention on the Twitter Developer Display Guidelines so I can understand the changes I’ll see to my favorite Twitter client; Twitterrific.
The guidelines will make our Twitter experience more consistent, boy howdy. Basically every Twitter client will look pretty much the same or it won’t be allowed to use the Twitter API, and a client that can’t use the API is useless.
Please note, if you’re using a Twitter provided client, these rules don’t apply, so you have nothing to worry about.
How do the various clients display Tweets in the Timeline? See the Timelines section in Display Guidelines.
Twitterrific
Twitterrific is my favorite client because it’s darned simple, great UX and UI design. Twitterrific is unique amongst the three clients we’ll examine because it shows a reply icon in every tweet. Note the arrow in the lower right corner of the image. Tapping on that icon will display a menu of choices that includes Reply, Direct Message, Retweet, and Retweet with Comment. Not even Twitter’s native iOS client provides this functionality.
Twitterrific: What needs fixing?
I use the term fixing loosely. Here is a list of the rules Twitterrific breaks, according to the Display Guidelines.
- Tweet Author
- The user’s name and @username should be displayed on one line, with the name first.
- Retweets
- If the Tweet being displayed is a Retweet, the name of the user who Retweeted it and the Retweet icon must be displayed under the Tweet text. e.g. “Retweeted by Josh Brewer”. The name should link to the the Retweeting user’s profile [1].
The @username doesn’t appear in the tweet and the retweeted by text doesn’t show below the tweet. It’s not seen here, but the retweet text displays to the right of the users name. One of the great things about Twitterrific is how it displays tweets in different colors depending on the context of the tweet. I’m not sure how Twitter will feel about that, but the guideline doesn’t call it out.
That’s not so bad, but it does mean Iconfactory will need to fix some things.
Tweetbot
Tweetbot: What needs fixing?
- Tweet Author
- The user’s name and @username should be displayed on one line, with the name first.
- The avatar must be positioned to the left of the name, @username, and Tweet text.
- Timestamps
- Tweet timestamp should be displayed in the top right corner.
- Retweets
- If the Tweet being displayed is a Retweet, the name of the user who Retweeted it and the Retweet icon must be displayed under the Tweet text. e.g. “Retweeted by Josh Brewer”. The name should link to the the Retweeting user’s profile [1].
Tapbots has a bit of work. In most cases the users avatar is displayed in the proper position, unless its your tweet, then it’s on the right. That’s an easy fix for them. Once that is fixed the timestamp will move to the proper position in the upper right corner. The Retweets item is interesting. The rule states it should display the name of the user who retweeted it. Tweetbot does that, sort of. If the retweet was by you it displays “Retweeted by You”, which doesn’t fit the rule to the letter.
Twitter: What needs fixing?
- Retweets
- If the Tweet being displayed is a Retweet, the name of the user who Retweeted it and the Retweet icon must be displayed under the Tweet text. e.g. “Retweeted by Josh Brewer”. The name should link to the the Retweeting user’s profile [1].
Not surprisingly Twitter does the best job of following the rules, but they do break this one. In the Twitter iOS client a retweet icon is display in the upper right hand corner of the tweet and the user’s name isn’t displayed.
Random Note
In the Individual Tweet section under the Branding bullet point this is listed.
The Twitter logo or Follow button for the Tweet author must always be displayed in the top right corner.
Emphasis on the word Tweet is mine. Twitter didn’t coin the term “Tweet”, the fine folks at Iconfactory did.
