I am a software engineer based out of Seattle, WA
I've done a lot of mobile development. From the small platforms, such as WebOS (great platform, terrible performance) and the Blackberry Playbook (I. Hate. Flash.), to Apple's iOS. One realm I'd never set foot in before today is the world of Android.
Read "The Nightmare of Android App Publishing"In case you didn’t hear, Apple announced the iPhone 5, new iPod Touch, and new iPod Nano. While I personally didn’t expect the appearance of an iPad Mini at this event, it does leave me wondering exactly where the iPad Mini will fit in.
The new iPod/iPad pricing lineup consists of the following:
So, where exactly does the iPad Mini fit in? At $399? That’s not exactly competitive compared to Amazon’s new Kindle Fire HD, which starts at $199. It’d be pretty easy for someone to say, “the iPad Mini is double the price of the Fire and is the same size.” And the larger Kindle Fire HD 8.9", which is closer to the original iPad’s size, is only $300.
But Apple wouldn’t price the iPad Mini at $299– the same price as the iPod Touch–which leaves one price point left: $350. This is still cheap enough in the consumer’s mind (it isn’t “$400”), and yet it doesn’t occupy the price point of the iPod Touch. It also distances it from the regular sized iPad.
In any event, you certainly won’t be seeing an iPad Mini for $299 or less.
Read "Where Does the iPad Mini Fit In?"Every morning, I wake up, open my laptop, and open a specific set of sites. I eat my breakfast while reading, save some pages for the bus ride, and then head to work. Every morning, it’s the same set of sites.
Hacker News is a new favorite of mine. It’s a great resource for some good articles to read. Engadget, despite having a poor reputation for the quality of its comments, is still a great tech blog. The Verge is relatively new, but like Engadget, it’s a great place for news on computers and electronics.
And there’s Lifehacker, which has some interesting tips and tricks, while Macrumors has all of the Mac news I could possibly need.
There’s also my Twitter feed. I follow a couple of Node.JS news bots, as well as some designers, developers, and products such as the Pebble. It makes for a great source of quick news snippets.
And then there’s Gizmodo.
Read "Underpants and Non Existent Touch Screens: The Decline of Gizmodo"Update: The experiment has been taken down due to Nodejitsu shutting down their free plans. I'll look into reuploading it at some point.
I've been working pretty hard on one of my projects and decided to take a small break and do a little experiment. A while ago (years?), I saw a website that allowed anyone to type anywhere on the screen. I decided to take a couple of hours tonight and recreate it using Node.JS.
My version of the Wall of Text app is available here.
It's built with Node.JS, Socket.IO, and Express (which really was unnecessary, but I was lazy and didn't want to work with the vanilla Node.JS HTTP server). Nodejitsu is providing the hosting.
I'm looking into making it into an infinite canvas, but for now, it extends as far as your screen goes. I suppose if you had a really big screen it would go infinitely... Those with 1080p+ monitors will be able to see beyond those with smaller resolutions. It's sort of an exclusive club if you can see the text on the outskirts of the wall ;)
The wall resets every six hours and shows the number of users connected in the bottom right hand corner of the screen.
tl;dr
See it here.
Read "Wall of Text Experiment with Node.js"Around a year and a half ago my Pre-AP English class was assigned a culminating project. This graduation requirement consisted of a 2500 word paper as well as a short presentation. We were prompted to choose a point of contention in the modern world, pose it as a question, gather arguments from debates and other sources, and format it as an essay to convince the reader of a certain position.
I chose, “is technology making us stupider?”
Read "Moore's Law of the Mind: How Technology is Changing the Way We Think for the Better"Recently I read a Node.JS framework roundup on OCDevel comparing Derby.JS, Meteor, SocketStream, TowerJS, and Express. The author expressed preference for Derby.JS, but I’m not 100% convinced that is really the best choice.
Don’t get me wrong– I think Derby.js is a fantastic (start) of a framework, and I would love to be able to use it, but I can’t for one simple, but big, reason. It’s no where near production ready.
Read "The (Odd) State of Node.js and its Frameworks"Around eight years ago, I sat down at the computer for the first time as a programmer. Little did I know, the simple, tacky website I built was the first step towards the person I am today.
I still remember the two paned, frame based website I built. It was terrible, with solid yellow backgrounds, and existed solely to show off photos of my new dog. This was back in the day when Microsoft FrontPage still ruled. During the winter, I made snowflakes drift down the page slowly using Javascript snippets from various websites, and during a power outage one year I built a Flash version of the site that mirrored my dark house with only virtual candle to light up the content. Really, everything I made or did was seen by a handful of people that landed on my site from a Google query. And I still have no clue exactly what they searched to get there.
Recently, on a website called Forrst, someone posted a question: “how did you all get in the position that you all are in?”
Read "Build Something Useless"Recently, there was a flurry of tweets that appeared on my Twitter timeline talking about Derby.js. I’ve never used a framework that did so much for you– realtime synchronization of the client and server. Essentially, this enables one to write an application in which two users edit the same text field–live–without writing too much code yourself. Derby handles all of the synchronization of the models and views. Think Google Docs collaborative editing.
That’s great, but after further investigation, it seems like Derby.js isn’t quite as mature as I’d like– it’s not 1.0 yet. To be fair, neither is Node.js (the platform behind Derby) or Meteor, but there seems to be quite a bit missing from Derby. For example, as far as I can tell, there’s no easy way to handle sessions. This may be a result of a lack of documentation, but it appears that the developers behind Derby are working on authentication at this moment. If anyone has writeup on how to handle sessions in Derby, I’d live to hear about it.
The one framework I always see compared to Derby.js is called Meteor. Similar to Derby, it handles things such as updating views live across multiple clients, though Meteor does it somewhat differently. While Derby is designed to be easier to use with different types of database systems, Meteor works closely with MongoDB. In fact, the client API for accessing the database is almost exactly like what you’d expect on the server-side with something like Mongoose.
While there are some drawbacks and controversies surrounding the framework (see Fibers vs Callbacks), Meteor looks like a pretty interesting option when creating an app that requires realtime feedback. Personally, I’m more attracted to the traditional callback style of programming of Derby, but the lack of robust documentation and a large developer community behind it is a huge blow to Derby’s usefulness. This will change over time, but at a much slower rate than Meteor, which recently received $11M+ in funding. This financial backing ensures that Meteor will remain around and supported, and for developers who need a financially and developmentally stable framework, the funding will only make Meteor more appealing.
Today, I want to go over how to create a really simple Meteor app. Essentially, this is a writeup for Tom's Vimeo screencast. One major difference between my writeup and Tom's video tutorial is the way we handle events in Meteor. Rather than copying and pasting code from one of Meteor's examples, I take you step by step through a custom implementation of handling the enter key press to submit a message. Let's begin!
Read "Introduction to Realtime Web with Meteor and Node.js"A couple of years ago, I don’t remember being truly baffled by a captcha. In fact, reCAPTCHA was one of the better systems I’d seen. It wasn’t difficult to solve, and it seemed to work when I used it on my own websites.
Fast forward to 2012, and I am trying to log into my Envato Marketplace account on Graphic River. I haven’t been there in a few months, and recently I’ve been working on changing my passwords to be unique-per-site. Understandably, I forgot my password.
But I didn’t entirely forget my password— I knew there are three possible passwords, across two possible usernames. Rather than going through the entire reset password process, which is a hastle and a last resort, I decided to try and guess. After a couple of attempts and failures, I was presented with a reCAPTCHA.
Read "Captchas Are Becoming Ridiculous"I’m working on a new project for iOS, and instead of using Objective-C, I decided to use Appcelerator Titanium again to help speed up development— even though I said I would never use it again.
A long time ago (in the iPad 1 days), I used Appcelerator to build an app called LOL. The problem was, there was a huge memory leak caused by a bug in the framework. Images were not properly released, resulting in a pile up of memory. This was a huge issue because of the 256mb of RAM the iPad 1 had. I published the app after fixing some of the bugs in the framework myself, but there were still issues. I ended up rewriting the entire app natively in Objective-C.
Some two years later, I am back to iOS development. While I did work on a Mac OS X app between “LOL” and now, my Objective-C is rusty, and a lot has changed in the newest versions of iOS. Automatic reference counting (ARC) now solves my worst nightmare for me. Rather than relearn Objective-C, I opted to once again use Appcelerator.
Read "Debugging in Appcelerator Titanium"One reason I wanted to have a Raspberry Pi was to be able to cheaply run periodic scripts and monitoring apps. I could have easily left on a full PC and hid it in my closet, or I could have rented out another Amazon EC2 server, but in both cases, it’s quite expensive. With the dedicated PC, there is a significant up front cost, and depending on the power efficiency of the computer, it could cost me monthly as well in the form of an electricity bill. Amazon EC2, on the other hand, costs anywhere from $20 up to hundreds of dollars a month, which is fine if you need the full power of a server to run a website, but not ok for hacking together some stuff.
With the Raspberry Pi, I have a low cost ($35) and low power device that I can always leave on, without worrying about heat building up in a case or a large power bill— after all, the entire thing runs on a Micro USB port.
Read "Using the Raspberry Pi to Send Push Notifications"I've been running my Raspberry Pi on a really old 2GB SanDisk Ultra SD card. It worked fine, but it wasn't fast, and there certainly wasn't that much free space to do anything on. After installing a bunch of packages, compiling Node.js, and cloning a couple of Git repositories, I ran out of space.
I had a Transcend 4GB SD card lying around, and wanted to transfer the entire contents of the older SD card to the larger one.
Read "Upgrading the Raspberry Pi's SD Card"Wondering how to install the Raspbian operating system on your Raspberry Pi? I've created a guide for that as well.
After receiving my Raspberry Pi, I began to look for a place to plug it into. I've always assumed that at least one of my two monitors sitting on my desk had an HDMI port, but I've always used DVI. I happened to be wrong-- neither of them had HDMI, meaning I had to commandeer a television somewhere else in my house.
I plugged the device into a 55" TV in my living room and booted it up with a 2GB SD card I had prepared earlier and began installing some things that would allow me to run the device headless. This is important, because I do not want to be forced to sit on the floor in front of the TV every time I want to use the Raspberry.
Read "Setting up the Raspberry Pi as a Headless Device"Today the Windows Phone and Silverlight teams at Microsoft released an update to the Silverlight Toolkit. The toolkit is an open source collection of controls that Windows Phone 7 developers can use in their applications. In addition, the kit is localized into all 21 languages supported by WP7 “Mango.”
The Windows Phone Developer Blog has a complete list of the new controls:
LongListSelector has been rebuilt and redesigned to take advantage of the new smooth scrolling and off-thread touch input support in ‘Mango’. This is a buttery-smooth control for showing lists, including grouping and jump list support.
MultiselectList control enables multiple selection for easily working with lists of data, similar to the Mail app’s capability.
LockablePivot adds a special mode to the Pivot control where only the current item is shown (often used with multiple selection).
ExpanderView is a primitive items control that can be used for expanding and collapsing items (like the threaded views in the Mail app).
HubTile lets you add beautiful, informative, animated tiles to your application, similar to the new People groups in ‘Mango’.
ContextMenu control has been reworked: performance improvements and visual consistency fixes.
ListPicker now supports multiple selection.
RecurringDaysPicker lets your users select a day of the week.
Date & Time Converters localized to 22 languages. The converters let developers easily display date and time in the user interface in one of the many styles found throughout the phone’s UI, from a short date like ‘7/19’ to relative times like ‘about a month ago’.
Page Transitions have improved performance for a more responsive feel.
PhoneTextBox is an early look at an enhanced text box with action icon support, watermarking, etc.
All error messages and interface elements have been localized to all of the supported languages, making for a great experience for users around the world.
Among these new controls and features is the PhoneTextBox, an addition developed by me during my internship at Microsoft this summer. This simple control adds a lot of new functionality to the Silverlight TextBox and is really easy to use.
To use it in your app, make sure that the toolkit is referenced in your application and that you have added the XML Namespace in your XAML. If you are already using the Toolkit in your app you won’t have to do this again.
After that’s done, you can simply replace any existing references of the Silverlight TextBox with the PhoneTextBox. For example:
<toolkit:PhoneTextBox Text="Hello World!" />
One of the three new features in the PhoneTextBox is "Hint Text." It's kind of like the Placeholder in HTML5. While the WP7 Developer Documentation states that there is a Watermark attribute to the TextBox, it was never implemented and is a dead end. The PhoneTextBox implements this feature by adding a couple of new properties:
Hint- A string that will be displayed in the text box when there is no Text and the control is not in focus.
HintStyle- This allows you to customize the style of the Hint.
The second feature of the PhoneTextBox is called the "Action Icon," a small, 26 by 26 pixel icon that sits in the (bottom) right hand corner. Developers can attach events to the icon that will be called when the icon is tapped.
ActionIcon- An ImageSource that will be displayed on the right side of the control. If the text box is multiline or supports wrapping, it will be shown in the bottom right.
ActionIconTapped- An event that is called when the action icon is tapped. The control will not get focus or open the keyboard when the icon is tapped.
Lastly, there is a length indicator built into the PhoneTextBox that can prevent users from entering more than a certain number of characters, but provide feedback as to how many characters they have already input.
This feature is more complex and flexible because it has a few different "modes" of operation. First, a developer can simply set a MaxLength and set the LengthIndicatorVisibility to true. The length indicator will always be visible and will display the number of characters entered into the text box out of the MaxLength. (ie. 125/140)
Secondly, a developer can set a LengthIndicatorThreshold. This property determines after how many characters the length indicator should pop down. For example, if the threshold is 20, the length indicator will be hidden if there are 18 characters in the text box. However, once 20 characters have been entered into the text box the length indicator will slide down.
Third, a "soft limit" can be imposed on the text box. In this case, a developer does not set a MaxLength, but rather sets a DisplayedMaxLength. In this scenario, the user can enter more than DisplayedMaxLength characters, much like how the Messaging app behaves in "Mango" for text messages.
LengthIndicatorVisibility- A boolean that determines whether the length indicator is visible or not.
LengthIndicatorThreshold- An integer that determines when the length indicator hides or slides down. Note that LengthIndicatorVisibility must be set to true if you ever want the length indicator to be shown.
DisplayedMaxLength- An integer that overrides the default behavior of showing the format N/MaxLength, where N is the number of characters entered. If DisplayedMaxLength is set, the format will be N/DisplayedMaxLength.
You can also check out the sample app included with the Toolkit to see how you can mix and match these different components.
This is a great new update to the Silverlight Toolkit and I am excited to be a part of this release. If you have any feedback, feel free to use the Issue Tracker on CodePlex.
P.S. If you are using the PhoneTextBox in your app, I'd love to hear from you!
Read "PhoneTextBox in the Silverlight Toolkit"