Connascence What Now?
June 9, 2012 by dave@kiwiluv.com · Leave a Comment
I attended the Philly ETE event recently (actually a few months ago) and had the email that they had posted videos of many of the sessions on their site. Although we’ve been head down on 7 Regent Lane lately and it’s been quiet here, this is one of my favorites. Aaron “Tenderlove” Patterson presented as well but unfortunately they didn’t post that one. Enjoy.
ETE 2012 – Jim Weirich – Connascence Examined from Chariot Solutions on Vimeo.
Philly Tech Week – Emerging Tech for the Enterprise Conference
May 7, 2011 by dave@kiwiluv.com · Leave a Comment
Karen and I both got to attend the Emerging Technologies for the Enterprise conference a week or so ago. Probably not as cool as her trip to Web 2.0, but there were some great speakers. Here’s some of the talks I sat in on.
- Yehuda Katz spoke about Rails engines in Rails 3.1. Rails is maturing nicely. This will make it much easier to segment functionality in complex apps. He also spoke on SproutCore, which I’m increasingly curious about and regret not attending…too many great talks.
- Jonathan Stark talked about developing native mobile apps using HTML, CSS and Javascript. This is a trend we’re really interested in, but were disappointed with our first foray into these frameworks. The one he discussed directly was PhoneGap and the JQTouch library. These frameworks will continue to mature and I’m sure they’ll be more and more viable as time goes on. PhoneGap fell into the trap of creating XCode templates, which not a public standard, and XCode 4 broke it. I think it’s time to give these frameworks another look. Dave Johnson of Nitobi also gave a talk on the history and future of PhoneGap.
- I had a chat with Dan Allen and Lincoln Baxter III over lunch about Android development and how Objective-C for IOS makes my brain hurt. Then I attended their Java EE 6 talk. I use Java and Java EE extensively in my day job, but don’t touch it otherwise except for Android development. Java EE used to be a laughingstock and even Java zealots would only touch certain parts of it. It looks like it’s gotten to the point where it’s quite usable.
- Finally, my personal favorite was Ryan Dahl’s talk on Node.js. I’m growing weary of large, full stack MVC frameworks and getting curious about fast and scalable distributed systems the more our products force us into emphasizing mobile clients and de-emphasizing the actual web app. Node.js is an awesome took to build systems like that. Now I’m dying to find a project just to try it out.
I was a bit underwhelmed by the keynote speakers. Not because they were bad, but the topics weren’t interesting to me. Judging by the number of people lingering outside of the ballroom over breakfast, I’m not the only one.
All of the code and presentations are available on the sessions page and is well worth a look.
Scale Fail?
April 18, 2011 by dave@kiwiluv.com · Leave a Comment
A colleague shared this one with me and it cracked me up, so I couldn’t resist posting it. I have a foot in both worlds. My day job involves systems with millions of clients and zero tolerance for downtime. Our venture does Web 2.0ish stuff using Rails. You hear a lot about MVC (minimum viable product) these days, and for kiwiluv products, which are as yet unproven, we adhere to that philosophy. Yes, I know full well that we’ll have to pump some more work into it to get it to scale, but the point is to see if you get traction in order to figure out if that next wave of investment is worth it.
On the other hand, if you have a system where you know full well it’s got to handle gazillions of users with no downtime, it’s irresponsible not to sharpen your pencils and use a little piece of your brain to make sure the wheels aren’t going to come flying off.
Either that or find a nice landing page with a cute “Fail Whale”esque picture for people to joke about when your servers fly apart at the seams.
By the way, if you’re concerned about this kind of thing you should be reading the High Scalability blog. There’s good stuff there so check it out.
iTunes Bloat
April 6, 2010 by dave@kiwiluv.com · Leave a Comment
I admire and use many Apple products because they focus on usability and simplicity. Many criticize them because they don’t allow you to do what you want in favor of what “The Steve” thinks you want. Still, if I have to sit down in front of a computer or MP3 player and use it, I’d pick Apple anytime.
So what happened to iTunes that made it so hideously complicated and bloated? The last update removed the contextual menu option to mark all items as watched which seriously annoys me. Apple, iTunes has hit that critical point where it’s collapsing under it’s own weight. Fix it…please.
20 Gorgeous Web Applications from Design Shack
April 4, 2010 by dave@kiwiluv.com · Leave a Comment
The folks at Design Shack published a list of 20 Gorgeous Web Applications. The one above is a simple To-Do application called TeuxDeux. I haven’t used TeuxDeux, but liked the interface. Web design has come a long way since my first foray into it and these 20 are definitely worth a look.
The simplest thing that could possibly work…
April 2, 2010 by dave@kiwiluv.com · Leave a Comment
This is one of the battle cries of the agile software movement. Agile is so prolific these days that I feel we’re loosing sight of the basics sometimes. My team at work just did a trial of a popular SCRUM tool and when faced with the prospect of migrating back to the corporate standard, they elected to stay with post-it’s, index cards and spreadsheets to manage their project. It’s working well.
But I digress. While implementing the Android application portion of our product, I find myself falling into a common trap for technical types. Specifically, as I’m working on a feature, class, view or some other major component of the application I keep trying to make it feature complete and fully bulletproof the first time. I know my partner falls into the same trap, but more focused on the aesthetics of the web interface. These things are critically important, but not now. We’re learning new technologies and it’s better to get these things out with limited functionality than to keep them in the incubator forever. I’ve probably lost a good day or two because I wanted our corporate logo displayed on a silly splash screen. What I should have been doing is focusing on the authentication logic and getting the application so it can login and exchange data with our Rails application.
So, in terms of login to our rails app, what is the simplest thing that could possibly work?
- A text field for name and password and a login button.
- An HTTP post to the Rails app with that data in cleartext.
- Parsing the response for success or failure.
Is that industrial strength? Absolutely not! But it is enough to get something deployed and working. You can add MD5 hashing, masking of the password fields, secure authentication, cookies, etc. later. So, as you do your development make sure you decompose things into the simplest thing that could possibly work. In this example, start with dumb unencrypted login with a user name and password. Next iteration, add masking of the password. Then, hash the password for security. Next add protection for cross site scripting vulnerabilities. Before you know it, you’re there…
A journey of a thousand miles begins with a single step. Lao-tzu 604-531 BC. I guess he was an agile software developer.
The Business is Pleasure blog has some more thoughts on keeping it simple…
http://bip.softwarejewel.com/business/losing-sight-of-the-basics-1999/
HTTP Posts in Android
April 1, 2010 by dave@kiwiluv.com · Leave a Comment
I finally turned my attention to exchanging data with our web application from Android. Previously, I’d been simply using curl to play around with the interfaces my partner developed. I’m having fun re-entering the Java world and programming for Android is a breeze. Here’s the experimental code snippet I threw together to post a user id, lat and lon to our location interface from an Android device.
private void postLocation() {
Toast.makeText(Login.this, "Posting Location", Toast.LENGTH_SHORT).show();
// Create a new HttpClient and Post Header
HttpClient httpclient = new DefaultHttpClient();
HttpPost httppost = new HttpPost("http://yourrailsapp.heroku.com/locations");
try {
// Add your data
List<NameValuePair> nameValuePairs = new ArrayList<NameValuePair>(3);
nameValuePairs.add(new BasicNameValuePair("location[userid]", "blah"));
nameValuePairs.add(new BasicNameValuePair("location[lat]", "11.1111"));
nameValuePairs.add(new BasicNameValuePair("location[lon]", "22.2222"));
httppost.setEntity(new UrlEncodedFormEntity(nameValuePairs));
// Execute HTTP Post Request
HttpResponse response = httpclient.execute(httppost);
} catch (ClientProtocolException e) {
// TODO Auto-generated catch block
Toast.makeText(Login.this, "Client Protocol Exception", Toast.LENGTH_SHORT).show();
} catch (IOException e) {
// TODO Auto-generated catch block
Toast.makeText(Login.this, "IO Exception", Toast.LENGTH_SHORT).show();
}
}
Couldn’t be easier! Now time to build the real thing…
Architecture Thoughts – What should you not do in a UI thread???
March 27, 2010 by dave@kiwiluv.com · Leave a Comment
The Android portion of our first application is taking shape and in implementing the HTTP interface to our web application I’m reminded of a few basic rules which I need to apply during my Android development, but which apply to the web portion and many other platforms as well.
Don’t do much real work within your user interface threads.
We have a simple screen on our Android app. It’s just a login, password and a button to initiate the login process. When a user clicks on it, the credentials are bundled up and passed to the web application for authentication. The thing is, this happens over the internet. Most IP networks are non-deterministic and the Internet can be downright random in terms of response time. The last thing you want to do is to annoy your user with a frozen login screen because in the case of mobile devices, throwing them can cause eye and head injuries to those near you. My Motorola Droid, for example, is quite aerodynamic and is also optimally shaped for pond skipping.
Here’s some general guidelines to follow:
- Separate processing which is not specific to gathering user input and presenting data to the user to other parts of the application. This is basically the Model View Controller (MVC) way of doing things. Once the UI gathers data from the user and your application has to go do stuff with it, send it elsewhere so you do not have to deal with the maintenance nightmare of having business logic mixed in with your UI code. Back in the early days of ASP and PHP, many nightmares were created with database access, business logic and other processing being done with complex code buried in the page. This is an example from the web, but you can just as easily commit the same sin in a mobile UI, a Java Swing or .NET Form app.
- Speaking of separate processing, if you do not know precisely how long it will take for the processing to complete spawn a separate process, task or thread to do it. If it is not appropriate for the user to do anything else in the app while this type of processing is taking place, give them a status bar, OS-X like beachball (hate those things), or some other indication that the application is alive, but busy doing it’s master’s bidding. On the other hand, if the user can do other stuff while the background processing is going on, let them do it…just grey out the parts that should be off limits until the background processing should be done.
- Even if you don’t know how long background processing will take, figure out how long is a reasonable time to wait and implement a timeout. When the time expires you’ll need to a) abort the process and have it clean up after itself and b) let the user know and give him or her control of the application again.
Breaking these rules cause some pretty obvious bad behavior in native apps (Java, Win32, Android, iPhone, etc.) so usually those get cleaned up. In the web world, I’ve seen many web sites from large, well funded companies that have issues that could have been avoided.