Recently I’ve been making the transition from my own Amazon EC2 server to Heroku. I’ve had some experience in the past with managing servers, but ultimately, I’m a developer, not a sysadmin. This meant that I was constantly hacking together a server that worked, but it never ran particularly well.
I recently completed the second level of Computer Science courses (CSE 143) at the University of Washington. If you know me and talk to me in person, you probably know that I am not majoring in Computer Science, and would go so far to say I actually dislike the major. While this is a topic for another day, CSE tests have always bugged me.
The basic level Computer Science tests are outdated, and in my opinion, not necessarily indicative of a student’s true programming skill.
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.
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.
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!
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.
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.
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!