Scala and ActionScript

Posted in Eric Daugherty on November 30th, 2009 by admin
Like many experienced Java programmers, I've played with several other languages and platforms over time. While most development languages are not game changing on their own, they can have an impact on the speed and level of enjoyment of a developer. Development languages are like a carpenter's tools. Most tools won't change they house an experienced carpenter can build, but they may make the experience more enjoyable.

With that caveat in mind, I wanted to explore my (current) preferred toolchain, Scala and ActionScript (Flex). Not only are both languages powerful and enjoyable in their own right, their similar syntax and easy integration provide a powerful combination.

Scala is:
"... a general purpose programming language designed to express common programming patterns in a concise, elegant, and type-safe way. It smoothly integrates features of object-oriented and functional languages, enabling Java and other programmers to be more productive."
Scala brings the benefits of a functional language, the accessibility of an object-oriented language and the power of the Java platform. I find the concise yet familiar syntax a joy to work with.

ActionScript is a dynamic language based on ECMAScript used to develop Flex applications. ActionScript brings the familiarity and dynamic nature of JavaScript, with the addition of more object-oriented features, and a powerful Flex API.

While there are some major differences in these languages, their basic syntax is very similar. To define a 'POJO' (where J is really Scala or ActionScript):

ActionScript:
package com.ericdaugherty.sample
{
public class Person
{

public var firstName:String;
public var lastName:String;
public var middleInitial:String;
}
}
Scala:
package com.ericdaugherty.sample

class Person {

var firstName:String = ""
var lastName:String = ""
var middleInitial:String = ""
}
While they are very similar, there are a few differences:

  • Scala defaults properties and functions to public, so you save on some boilerplate code.

  • In Scala, every variable must be initialized, or the compiler will assume it is abstract.

  • While this example provided explicit types, they can be inferred by the compiler.

In this example, the properties are still all statically typed Strings, but the explicit definition is unnecessary:
package com.ericdaugherty.sample

class Person {

var firstName = ""
var lastName = ""
var middleInitial = ""
}
You can leave off the types in ActionScript as well. However, this results in an untyped variable instead of using type inference to infer the static type. It also results in the following compiler warning (using Flex Builder):
1008: variable 'firstName' has no type declaration.
Finally, Flex Builder does not support code completion without explicit typing, so in practice ActionScript really requires explicit type definition.

In both languages, you can define explicit get/set behavior instead of a generic property. To only define a setter in ActionScript:
private var _firstName:String;

public function set firstName(firstName:String) {
_firstName = firstName.toLowerCase();
}
In Scala:
var _firstName = ""

def firstName_=(firstName:String) {
_firstName = firstName
}

In Scala and ActionScript, the trailing semicolons are optional, reducing the need for superfluous characters.

While these comparisons are very superficial, they do make context switching between Scala and ActionScript a bit easer. However, it is important to understand the differences in implementation. Sometimes similar syntaxes can disguise vast differences.

Note: While this example makes use of 'var' definitions in Scala, in practice a functional program would use the final 'val' definitions instead. One of my most common muscle memory issues is typing val in ActionScript instead of var.

DSL Woes

Posted in Eric Daugherty on November 30th, 2009 by admin
I've been struggling with my DSL connection for a while now. Over the past week it became intolerable, and I dug in to investigate this weekend.

I had been experiencing intermittent outages, which I wrote off as bad service (Ameritch and I have had issues in the past*). Over the past week I started experiencing significant packet loss (>30% on pings to the ISP's DNS server), so I knew it was getting worse.

Doing some basic troubleshooting, I thought I heard 'noise' on the line, so I replaced the DSL filter I setup. No luck.

I gave up and called SBC (Ameritech). They immediately acknowledged that something wasn't right, and referred me to their troubleshooting center. The next morning I got an automated call that I needed to call them to discuss. After some debugging on the phone, they decided that it was probably my DSL Modem. Since it was > 5 years old they thought it was probably starting to flake. I went out and bought a new one.

The new modems actually have a nice web interface so you can see what is going on. Unfortunately, it told me that my downstream connection was ~ 500 Kbps, while my upstream was 640 Kbps. Yes, this is WRONG. The downstream should have been 6 Mbps, or ~6,000Kbps. I called them back, and they agreed it was still wrong, and dispatched a technician, with the warning that there may be a charge if the problem is in my internal wiring.

I decided to verify that the issue was external, so I took my laptop, DSL Modem, and some wires outside and plugged them directly into the telephone box on the outside of my house. To my surprise it connected at full speed, indicating that the issue really was internal.

I tried some simple debugging (unplugging devices, etc.), but eventually just ran a fresh line from the inside junction box to my DSL modem. Success!

I'm a little annoyed I couldn't find the problem, but there must be some type of interference on the wiring inside the house. However, since it is all effectively hard wired together, it is nearly impossible (well, given a reasonable amount of effort) to track down. So, I'll have to settle for good enough.


* 'Back in the day' I had a frustrating experience with Ameritch (or whoever they were back then). There was noise on our line, causing my modem all sorts of problems. What really annoyed me was when they told me they only supported speeds up to 9600 bps, and if I was using a faster modem I was simply out of luck. It took a while but I convinced them that the issue was bad enough I could hear with my own ears. They ended up dispatching a truck and found that there was 'water in the line' on their end.

iTunes Export 2.1 Released

Posted in Eric Daugherty on November 25th, 2009 by admin
This release of iTunes Export provides some additional features requested after the 2.0 release. These features include:

The ability to override the file path separator used. This is useful when you will be using the playlist on a different operating system.

iTunes 9 File Structure. iTunes changed the file structure starting with version 9, with a separate 'Music' folder under the iTunes Media folder. This version now includes the Music folder as part of the musicFolder, excluding it from the path when using file copy with the iTunes Structure.

The GUI version now remembers your last settings and will use those as the new defaults. There are buttons to restore the initial defaults if you wish to revert to the normal defaults.

The new version can be downloaded from the project homepage: http://www.ericdaugherty.com/dev/itunesexport/

If you find any issues or have questions please email me (eric@ericdaugherty.com). Please include which application and version (GUI or Console, 2.1 etc.) of iTunes Export and the operating system you are using.

Embedding PHP in HTML files and GoDaddy Statistics

Posted in Eric Daugherty on November 24th, 2009 by admin
I host my site at GoDaddy, for better or worse. The site is comprised entirely of 'static' HTML pages at GoDaddy. The Blog is managed using Blogger, but it publishes HTML files via FTP to GoDaddy, and the rest of the content is HTML files I manage directly.

I wanted to avoid the redundant header/footer/etc. structures in my pages since I was editing them manually. So, I setup my site to parse the HTML files as PHP files, and then used PHP includes:
<?php include 'head.php' ?>
to build the pages on the fly. This allows me to maintain each page using simple HTML and avoid duplication of boilerplate HTML. This works because I added the following line to the .htaccess file:
AddHandler x-httpd-php .html .htm
This solutions works well, but unfortunately destroys GoDaddy's web statistics (/stats/) output. Apache attempts to parse these html files as well, but because of how they setup permissions (you have none), it fails and results in an HTTP 500 error.

This would be a simple fix if I could edit the .htaccess file in the stats directory. I could simply override the .html handler back to the default, and avoid the PHP processing.

Instead, it looks like my options are:
  • FTP the files to my local machine and view them there.
  • Create a script that copies them to a different directory (with the correct permissions and .htaccess override) and view them there.
  • Change my files to .htm or another extension that doesn't conflict with the /stats files (.html).
  • Get Creative.
Changing the file extensions isn't really an option for me as the entire point of mapping the .html files as PHP is to maintain all the existing incoming links without doing tons of rewrites. I view that stats infrequently enough that the first option is workable, but it is annoying. So I got creative...

My hack was simply to create a PHP file that reads the files out of the /stats directory. Here is a crude version:
<?php
$file=fopen("stats/INDEX.html","r");
while(!feof($file))
{
echo fgets($file);
}
fclose($file);
?>
You could expand this to be dynamically driven from a request parameter. Again, this is a HACK, but for the specific purpose it works. It should of course be secured if you want to maintain the security defined in the original /stats directory.

Habit 7: Principles Are More Important Than Results

Posted in Dave Rodenbaugh on November 23rd, 2009 by admin

Our last installment today is about the Great Ivory Tower of Standards and Architecture.  In case you missed the previous bunch:

Seven Habits of Highly Dysfunctional Enterprise Developers:

  1. Blame Everyone But Yourself
  2. Confuse Motion With Action
  3. Use Complexity To Demonstrate Intelligence
  4. Keep Important Information Secret And Safe
  5. Fix It Later
  6. Reuse Is Overrated
  7. Principles Are More Important Than Results

Principles Are More Important Than Results

ivory_tower

Beware the Ivory Tower

Ever work on a project where some group (or some person) in your company espouses standards above all?

“You absolutely must follow our standards to the letter.  We’ll be having daily code and design reviews, anything out of compliance will of course, be refactored to meet the corporate standards immediately”

Principles and best practices are great things to engender on a project.  A highly respected architect friend of mine said to me over and over, “It’s better to be consistent than right”.  Consistency gives predictability to people looking at code for the first time.  They learn what to expect and it reduces up-to-speed time for new developers.  It also creates mini “code templates” in your work patterns to speed things up as you develop.

You can take this too far.  Projects where standards are used like a whip are demoralizing and turn action into motion purely for the sake of consistency.  Remember:  Your goal is to ship a finished product that meets the customer’s requirements, on time and under budget.  Following standards is part of that but creating painfully complex standards and then demanding absolute adherence in this fashion is just torturing your developers.

Have standards, but keep them simple.  Standards exist to create consistency, not some absolute right-or-wrong litmus test for code.  Balance is important–shipping a product ad-hoc without any standards is a recipe for disaster during your first bug fix or maintenance release, but following each and every standard down to the comma is just wasting cycles.  Don’t err on the side of extremes either way.

In summary:

A good developer knows that there is more to development than programming.
A great developer knows that there is more to development than development.

Got a habit that I missed?  Sound out below!

Related posts:

  1. Habit 5: Fix It Later We examine the power of procrastination in today’s post, and...
  2. Habit 2: Confuse Motion With Action We explore the difference between work and heat in today’s...
  3. Habit 6: Reuse Is For Wimps Today’s Habit is brought to you by the letter “R”...

Related posts brought to you by Yet Another Related Posts Plugin.

Habit 6: Reuse Is For Wimps

Posted in Dave Rodenbaugh on November 20th, 2009 by admin

Today’s Habit is brought to you by the letter “R” and the number 1.

Seven Habits of Highly Dysfunctional Enterprise Developers:

  1. Blame Everyone But Yourself
  2. Confuse Motion With Action
  3. Use Complexity To Demonstrate Intelligence
  4. Keep Important Information Secret And Safe
  5. Fix It Later
  6. Reuse Is Overrated
  7. Principles Are More Important Than Results

Reuse Is For Wimps

recycle

Not Just For Plastic, Glass and Cans

Feeling that urge to rewrite qsort?  Convinced you can write a better Hibernate than Hibernate?  Positive that there is no XML parser out there that will suffice for your project?  Um.  Put down that Erlang compiler a sec and listen.

I completely understand why these urges come up.  We love to solve problems.  And sometimes, writing a billing application isn’t nearly as fun as say, creating a custom persistence layer that converts XML to binary ZIP and inserts it into a BLOB in the database.  But you won’t get a promotion because you reinvented the GOTO in your custom Haskell extension.  You might get a promotion because you shipped a working product on time, under budget that delighted your customers.

The goal of every software project is to launch.  Anything that gets you to launch quicker is good.  Previously developed libraries, even beta-grade ones, can be a win for you and your team.  That’s not to say you should create a Frankenapp by bolting every Open Source project together within reach.  But making judicious use of the right technologies can substantially reduce your time to market.

The one (and I do mean ONE exception) is creating something that is part of your core competency.  If you’re Intuit, then accounting software is your core competency and you’d better write some cool 401(k) prediction algorithms to help people use Quicken more effectively.  But what about a web framework?  Intuit isn’t in the business of creating frameworks.  Should they write a brand new one?  Probably not.  Understand what you’re in the business of doing, and write THAT.  Find help for everything else, as much as you can.

No related posts.

Related posts brought to you by Yet Another Related Posts Plugin.

Habit 5: Fix It Later

Posted in Dave Rodenbaugh on November 19th, 2009 by admin

We examine the power of procrastination in today’s post, and why you should never underestimate the impact on your future.  If you missed the early habits, they’re linked here:

Seven Habits of Highly Dysfunctional Enterprise Developers:

  1. Blame Everyone But Yourself
  2. Confuse Motion With Action
  3. Use Complexity To Demonstrate Intelligence
  4. Keep Important Information Secret And Safe
  5. Fix It Later
  6. Reuse Is Overrated
  7. Principles Are More Important Than Results

Fix It Later

How many times have you said to yourself,

“Bah…I don’t have time to do that now.  I’ll fix it later…

bug_costs

Anything is More Believable When It's Graphed

Yeah, I thought so.  I do it too.  But a disciplined developer will stop right then and there, think about the future cost of that mistake and then correct it on the spot.  It’s the difference between knowledge and wisdom.

Comp Sci majors are taught from basic coursework (usually in their ONE software engineering capstone course, sadly) that the cost of fixing errors goes up non-linearly as you move forward in a project to later phases–fixing a bug in the requirements during say, design, is cheaper than fixing the same bug in production.  A practiced engineer will apply that knowledge to fix problems BEFORE they get into the next phase by proactively understanding the consequences now and altering the course of history.

The temptation (and sometimes the stick that is whacking you on the backside) is to say you don’t have time because of The Schedule.  The Schedule will always be there.  You’ll almost never work on an open-ended project with infinite time to “get things right.”  You will have to ship, eventually.  That comes with compromises.  We defer changes out of fear.  Fear of impacting others.  Fear of being wrong.  Fear of having more work to do.  What’s that you say?  “I’m the exception!  I can’t just go changing that class because it’s already in production and I don’t know what it will break.”   Thank you, that’s the point.  THAT bug made it to production because someone said, “I’ll fix it later.”  So fix it now.

Related posts:

  1. Habit 7: Principles Are More Important Than Results Our last installment today is about the Great Ivory Tower...

Related posts brought to you by Yet Another Related Posts Plugin.

Habit 4: Never Share Information

Posted in Dave Rodenbaugh on November 18th, 2009 by admin

Lessons from Lord of the Rings, why you really did learn all you needed to know in Kindergarten and the value of opening your kimono.

Seven Habits of Highly Dysfunctional Enterprise Developers:

  1. Blame Everyone But Yourself
  2. Confuse Motion With Action
  3. Use Complexity To Demonstrate Intelligence
  4. Keep Important Information Secret And Safe
  5. Fix It Later
  6. Reuse Is Overrated
  7. Principles Are More Important Than Results

Keep Important Information Secret And Safe

All that knowledge you’ve worked hard to acquire over the years…it should be jealously guarded, like a treasure in a cave.  Never shared.  My PREH-SHUSSSSS!

Filthy Colleagues-es!  They wants the Precious!

Filthy Colleagues-es! They wants the Precious!

Who are you, Gollum?  You may remember it didn’t work out so well for him.

The best developers actively share and disseminate their practices, tricks, tips and past pitfalls with everyone and anyone who will listen.  They teach and mentor new developers, write good documentation (OK, they at least write it…), send emails to the team letting them know about new tools and techniques for making things better.  They do Brown Bag seminars talking about the latest project and how it was useful to them, the company, or their peers.  They see problems in training and make up for it by creating Wikis for new team members.

There is no point in holding on to useful information that could make others better developers.  That is, unless you’re trying to stay in the same job forever.  Ask yourself, who do you want to work with on your next job?  The person who helped you write that complex algorithm on their lunch break, or the guy who hissed at you when you walked into his cube:  “Mine!  Stay away, filthy Hobbitses”.

Yeah, I thought so.

No related posts.

Related posts brought to you by Yet Another Related Posts Plugin.

Cairngorm: All the worst parts of Java

Posted in Jon Rose on November 17th, 2009 by jonr

Like many Flex developers, I came to Flex development after a long stay in the Java world. For many years, Java and the surrounding community provided an exciting technical playground. Overall, the community gave developers like myself an amazing set of tools and an excellent group of thought leaders. Yet, we can look back now and realize how many silly ideas there were at the height of Java. I have long thought that Cairngorm borrows on some of my least favorite of these bad ideas, and now it looks like they are continuing down that road.

Now, they are attempting to expand from just a framework to some sort of Flex MVC framework think-tank. Yakov Fain’s reaction to this is priceless:

First, let me ask Java developers a question. Imagine that one day you wake up and read the following announcement, “As of today, Spring framework is the foundation for delivering of successful J2EE projects. In contrast to earlier versions, many parts apply across frameworks. So, if you are using Struts, JSF, and especially Tapestry, just forget about all these complex to pronounce names. From now on, no matter what framework you use, you are actually using Spring’.

Some of you would think, “Yakov is either out of his mind or is writing this blog sitting in one of the coffeshops in Amsterdam”. Wrong! I’m just reading an announcement about the upcoming release of the popular Adobe framework Cairngorm 3: http://opensource.adobe.com/wiki/display/cairngorm/Cairngorm+3

When I first saw Cairngorm (post), it was easy to understand what they were trying to do, as the framework is so heavily influenced by the original version of Struts and the Core J2EE Patterns. Unfortunately, Struts was barely a fit for the original problems it was attempting to solve, and are completely inappropriate for building client-side applications within a real runtime. Struts used an adaptation of the MVC pattern called MVC2/Model 2, which was created to deal with building user interface within request/response model. This model is completely at odds with building a rich Internet application.

So, obviously, I find the move to hold Cairngorm up as a template for architecting Flex applications a bit concerning. Beyond that, one of the other things in the Java community that never proved to bring fruit was the desire to standardize anything and everything, which this idea seems born out of.  I am actually foggy at best with what they are trying to accomplish, and find it completely bizarre that they would try and morph a framework into this “thing.”  Do we really need some sort of Flex specific think tank on a long established pattern?  Also, it seems very bold to attempt to group the work of so many others under their umbrella.

Is this just an attempt to keep the brand name relevant of a framework whose time has come and gone?

Habit 3: Complexity Demonstrates Intelligence

Posted in Dave Rodenbaugh on November 17th, 2009 by admin

Smart people naturally create…chaos?  Today’s habit is about the value of parsimony in your work.  Previous habits linked here:

Seven Habits of Highly Dysfunctional Enterprise Developers:

  1. Blame Everyone But Yourself
  2. Confuse Motion With Action
  3. Use Complexity To Demonstrate Intelligence
  4. Keep Important Information Secret And Safe
  5. Fix It Later
  6. Reuse Is Overrated
  7. Principles Are More Important Than Results

Demonstrate Your Intelligence With Complexity

escher-relativity1

Ow, my head hurts...

Project complexity creeps in from two paths.  First, there’s accidental complexity.  As developers we love solving ALL kinds of problems–that’s usually why we choose this field.  Often times we start solving the problem before thinking about it first.  The result is stream-of-consciousness code, where even YOU won’t understand it in six months.  With comments.  As Mr. T would say, “I pity the fool”.

How about the developer that actively accidentally obfuscates their code by using counter intuitive algorithms, poorly named variables, or seven levels of indirection.  This intentional complexity is even more insane.  I’m not sure if this comes from some Napoleon complex in software, lack of training/experience or just a naive repertoire of coding tools.  Either way, it sucks for everyone else down the line from your code.

Simple code is easy to read, easy to maintain, and a joy to work on.  Sometimes, simple code will naturally evolve from complex code during the course of code reviews or pair programming efforts.  The best programmers I’ve ever worked with have one thing in common:  making complex things simpler.  And despite what I read about this Python library experience, simplicity pays for itself down the road.  Being afraid that a simple solution makes you appear less smart is crazy.  Want to prove how smart you are?  Try teaching some training class to your peers instead.

There are some easy ways to help fight both kinds of complexity:

  • Google the problem before you attempt solve it.  See if a solution already exists.  Understand that solution first.
  • If you only understand one solution to a problem, ask someone else for a different perspective, especially if you struggled with that answer.
  • Refactor if you don’t like it the first time.
  • Actively seek to reuse existing libraries.

Endeavor to make things easier for yourself and others.  The sanity you save may be your own.

Related posts:

  1. Habit 4: Never Share Information Lessons from Lord of the Rings, why you really did...
  2. Habit 2: Confuse Motion With Action We explore the difference between work and heat in today’s...
  3. Habit 7: Principles Are More Important Than Results Our last installment today is about the Great Ivory Tower...

Related posts brought to you by Yet Another Related Posts Plugin.