Amazon Announces Management Console for Simple Email Service (SES)

Posted in: Cloud Computing

In an email to customers today, Amazon announced a new addition to their web-based Management Console tool – the ability to manage Simple Email Service (SES) resources. Previously customers needed to use an API to manage SES resources.

From the announcement:

Today we’re excited to announce the immediate availability of the Management Console for Amazon Simple Email Service (Amazon SES), AWS’s highly scalable and cost-effective bulk and transactional email-sending service for businesses and developers.

The Amazon SES Management Console is a simple and intuitive web-based user interface for Amazon SES that allows you to do the following with a few clicks of your mouse:

- Check your sending quota and usage
- See your Amazon SES bounce, complaint, and rejection metrics over time
- Verify sender email addresses
- Send both formatted and raw test emails

Of course, all of this is still available via the API as well, so you can choose whichever method works best for you. Please note that you will still need to send your production email to Amazon SES through its APIs. Please see the API Reference for actions and data types.

Additionally, Amazon announced a public webinar to demonstrate the new Management Console features. You can register for the webinar here.

Amazon Announces Simple Queue Service (SQS) Support in Management Console

Posted in: Cloud Computing

Amazon just announced support for their Simple Queue Service (SQS) within the main web based Management Console. Previously you would have needed to use the API to manipulate SQS resources.

From the announcement:

We’re excited to announce today that we’ve added support for Amazon Simple Queue Service (Amazon SQS) to the AWS Management Console.

Amazon SQS offers a reliable and highly scalable queue-based messaging service which supports distributed application and makes it easy to exchange time-sensitive data between components or EC2 instances. The AWS Management Console adds the simplicity of a point-and-click web interface.

You can now create queues, set configurations and manage access – all from your browser.

Engage

Posted in:

I am a full-time consultant who is available to engage with clients remotely or onsite anywhere in the world (I currently hold dual-citizenship between Australia and the United States).

To discuss your specific needs, please call me on +1.650.336.5877, or email me at craig@craigsdickson.com, or use this Contact form, or download a copy of my resume from this page.

The following is an overview of the services I provide to clients:

Software Development Process Improvement

  • Coaching for Agile process evaluation, adoption or improvement, including Scrum, Lean, Kanban and Extreme Programming (XP)
  • Definition, refinement and documentation of team processes and practices
  • Definition of Quality Assurance and Quality Control standards
  • Integration of defect tracking systems with other tools and processes
  • Engagement with customers and requirements elicitation

Software Development Team Management

  • Job Description authoring
  • Salary range and benefits package definition
  • New candidate acquisition and screening
  • Team workspace design and office space evaluation
  • Skills assessment of existing resources
  • Collaboration strategies for teams

Vendor Management

  • New vendor discovery and screening
  • Vendor proposal reviews
  • Offshore vendor management, including onsite visits and reviews
  • One throat to choke multiple vendor management

Software Configuration Management (SCM)

  • Introduction of an SCM system to teams not already using one (Subversion, Git, CVS etc)
  • Subversion and CVS training
  • Subversion and CVS server installation and configuration
  • SCM process definition and documentation, including branching and merging processes
  • SCM system migration, particularly CVS to Subversion

Build Management

  • Implementation of Apache Maven and Apache Ant based build systems
  • Automation of builds, particularly in relation to a Continuous Integration system like CruiseControl or Hudson
  • Management and versioning of produced code artifacts, particularly in relation to an Artifact Repository like Nexus or Artifactory
  • Release numbering strategies and Alpha and Beta customer release programs

Software Architecture & Design

  • Enterprise-level system architecture definition, existing architecture reviews
  • New database design and existing database design review
  • Formal UML based architecture definition

Enterprise Java Development

  • Specialist in full-stack JavaEE development
  • Public API design and documentation for ISVs
  • Web service development and integration
  • Code reviews and performance tuning
  • Service Oriented Architecture (SOA) design and implementation

Web Development

  • HTML, JavaScript and CSS development
  • Integration of AJAX style JavaScript libraries including GWT, JQuery and ExtJS
  • Integration of Adobe Flash and Flex components

Automated Testing Strategies

  • Introduction of tools like JUnit and Sellenium to teams that currently do not do any automated testing
  • Integration of tests into automated build scripts and generation of metrics
  • Static analysis of codebase quality

Mobile Development

  • iPhone application design and development, specializing in integration to JavaEE based back ends
  • Web based mobile development

Social Media Strategy

  • Specializing in small to medium business that do not have dedicated in house Social Media resources
  • Evaluation of current Social Media presence
  • Recommendations for Social Media platforms based on particular business needs and goals
  • Evaluation of Location based services in relation to business needs and goals

Once again, to discuss your needs and to find out how I can help you, please contact me by phone on +1.650.336.5877, by email at craig@craigsdickson.com, or simply use this Contact form. If you would like more detailed information regarding my experience and qualifications, you can download a current copy of my professional resume from this page.

Zembly victim of Oracle takeover

Posted in: Enterprise Java

Just received this email from the Zembly team at Sun. They don’t specifically point the finger at Oracle, but it doesn’t take a genius to join these dots.

We regret to inform you that on November 30th, 2009 we will be suspending the zembly service.

More than three years ago, we started this project with the goal of making it easy to create next-generation Web apps. Our original tagline was “Build the web, using the web,” and the ideas we were incubating around platform-mediated Web applications, Web API mashups, and social programming were brand new.

We learned a lot along the way. Your confidence and enthusiasm helped us improve the project and do amazing things that we never imagined when we began this journey.

Thank you to everyone who’s been with us through the ups and downs. It’s heartening to see that many of the best ideas pioneered in zembly have started to appear elsewhere. With your support, we’re proud to have contributed to the DNA of the Web.

For more information about the zembly suspension, please refer to the FAQ section at http://zembly.com

Finally, if you have questions, please contact us at zembly-support@sun.com

All the best,

– The zembly team

Sun Microsystems, Inc.
4150 Network Circle
Santa Clara, CA 95054
Click here to unsubscribe

Design Patterns 15 Years Later

Posted in: Software Development Best Practices

It is one of the most venerated books in the world of Software Engineering. It is such an icon it even has its own nickname and even the acronym of the nickname is easily recognized by most software architecture and design zealots.

I am of course talking about Design Patterns: Elements of Reusable Object-Oriented Software by Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides. Also known simply as the Gang of Four book, or even more simply as just GoF.


I in fact never purchased the book myself, but I have definitely read it and it has been on my bookshelf for the best part of a decade now. When I first moved to the United States I moved into an apartment that was being rented and paid for by the company that hired me. It was the heady days of the .com explosion so there was a high rate of turnover at the company. When I moved into the apartment, it was clear that the previous occupant/employee had only just vacated and had left some personal belongings behind. One of the items carelessly discarded was a copy of Gof.

Now to be fair, the book will put the hardiest of readers to sleep pretty easily – it is most definitely a tome of knowledge, not a work of entertainment. But nonetheless, my copy is certainly worth the dead trees it is printed on.

As with many new ideas, there is rarely just one person thinking about them. It usually takes these visionaries getting together and coming up with some common terminology and cohesive thoughts to really launch the new idea into the mainstream. This is what GoF did for Design Patterns, and it is in this launching that its main value resides.

It is hard to believe that this book is already 15 years old. But InformIT has just published an interview with 3 of the gang (Vlissides died on Thanksgiving Day in 2005) to look back on the book, its influence on the Software Engineering industry since its release and whether in the rapidly changing world of app stores, mashups and the like, whether the book is still relevant.

InformIT: Design Patterns 15 Years Later: An Interview with Erich Gamma, Richard Helm, and Ralph Johnson > Design Patterns 15 Years Later: An Interview with Erich Gamma, Richard Helm, and Ralph Johnson

Java Persistence API (JPA) – A Brief Overview

Posted in: Enterprise Java

links for 2009-06-25

Posted in: Enterprise Java, Social Networking

What is a browser?

Posted in: Uncategorized

It seems like an easy question. A web browser has become so integral to today’s computing experience that it would be hard to imagine what a computer without one would be useful for.

But take a look at this video that Google has posted on YouTube.

So if we ignore that this video is produced by Google and so the results are obviously predisposed to further their own agenda, then I think there are still a few interesting things that come to mind when watching this.

Firstly, I think software developers can sometimes get a little myopic about who their customers are, and I definitely make that mistake myself sometimes. Much of my day revolves around my laptop and my web browser, but for a lot of people, perhaps most people, this is not the case. So we should be careful about making too many assumptions about what our users will or will not understand and how they will or will not use our software.

Secondly, I think that this kind of proves out that the whole debate about whether Microsoft ships Windows with IE embedded in the OS or not is kind of moot. As it turns out, there is a pretty large number of people that can’t identify what IE even is, let alone whether it is IE or Firefox.

Thirdly, the number of people who thought Google was the browser says a lot about what the web experience of most people is. They launch a piece of software (not called a “browser” apparently), they either go to google.com, or it is already their home page, they search (or browse if you will) for what they are looking for, click one of the links on the first page that shows up, and that is the Internet as far as they are concerned.

Fourthly, following on from the previous point, this only serves to reinforce the importance of SEO activities and making sure your site shows up high on that very first page of results on Google.

Fifthly (is that a word?), this might be reading too much into it, but maybe these people are the embodiment of the trend of the browser just simply becoming more and more ubiquitous when using a computer. The delineation between the OS and the browser is fading rapidly. The move towards SAAS style applications, web applications as apposed to just web sites and just generally more and more computing work being moved to the network and less and less being done locally anymore will see this trend continue.

Are you hiring a hacker, a coder or an engineer?

Posted in: Software Development Team Leadership

There are many types of developers who work in the IT industry. When it comes time to hire a new developer it can be tough to figure out which kind of developer you are interviewing. When I do an interview I try to place the candidate in one of 3 categories – hacker, coder or engineer.

The Hacker

How to spot one:

  • Has been coding since they were 12, but have no notable credentials (no college degree, no professional certifications etc)
  • Believes all problems can be solved with some kind of “script”
  • Is unable to answer questions related to emerging industry trends
  • Appears uninterested in training opportunities
  • Their answers will be 1 or 2 words in length and no matter how much you coax them, they will not expand on them
  • Has an unhealthy fascination with the game World of Warcraft, to the point it will probably affect their performance as an employee

When to hire one:
Hiring a hacker is always a gamble for a development role. Often they make better sys admins than actual developers, since they are quite comfortable working all-nighters in dark rooms (as long as there is a supply of energy drinks and pop-tarts). They can also thrive in a QA role where automation of repeating tasks is a key skill (hackers also tend to like to break things).

When not to hire one:
A Hacker can become a rogue and distracting element in your development team. If you are looking for a team member that will have a focus on quality and meeting deadlines, a Hacker is not for you. If you want an employee that will work a regular schedule that doesn’t include them showing up at 11am looking like they have had no sleep, then a Hacker is not for you. These are the kinds of employees that you find out have been running a personal ecommerce site piggybacked on one of your corporate servers for the last 6 months.


The Coder

How to spot one:

  • Probably has a degree, but has no professional credentials (no certifications etc.)
  • Can answer common programming questions, maybe even understands Object Oriented principles, but probably struggles to answer big picture architecture questions
  • Probably cannot answer questions related to emerging industry trends
  • Doesn’t have a strong interest in getting training, attending conferences or expanding their skills in general
  • You will have to work to get them to expand on their answers beyond 1 or 2 words
  • Their references are probably positive
  • They like to play World of Warcraft at least a couple of nights a week

When to hire one:
A Coder is usually a good hire if you are simply looking to increase your development bandwidth. They will be able to contribute to a project in terms of pumping out code, but will need a solid design or requirements to follow closely. You will also need to make sure there is an Engineer close by to keep an eye on them.

When not to hire one:
If you are looking for a people leader or a technology leader, a Coder is not for you. Also don’t expect to be able to have a philosophical discussion about the state of the software industry with a Coder.


The Engineer

How to spot one:

  • Has a degree, maybe even an advanced degree, but is not a new graduate. To be an Engineer, some real world exposure is needed to shake off the bad stuff they learned in college and develop their own ideas.
  • Has a strong opinion about industry trends
  • Asks questions about training opportunities and budgets for attending industry conferences
  • Can name some tech authors they like or industry luminaries they agree with
  • Asks questions about what development processes and tools are used at your company
  • May not be able to answer every low level code or syntax question you throw at them (this is not a concern, Engineers are usually thinking at a higher level and know how to quickly find the documentation about the API they want to use if they need to)
  • Is reasonably articulate and their answers are usually more than 1 or 2 words in length
  • The interview will be much more of a conversation than an interrogation
  • Are aware of the game World of Warcraft, but don’t seem to have time to play it because of all of the tech books and journals they are trying to keep up with

When to hire one:
In general, the Engineer is the employee you are looking for. Just like in sports where you have franchise players, a good Engineer or two on your team can make or break a whole company. They are going to push the envelope in terms of the pace of development, introducing new tools, technologies and ideas and also the basic way in which the team operates. If you are working on projects that require novel solutions to be created, you will need an Engineer, as a Coder will not bring this kind of skill to the table. Also if you want to be able to increase the number of tasks you can delegate, the Engineer is for you.

When not to hire one:
Depending on the project you are working on, an Engineer can sometimes be a bit like having a sledgehammer in your hand when all you want to do is tap in a small nail. If you are working on small simple projects, or the work is generally a matter of taking a set of pre-defined requirements and pumping out a solution that requires little thought, then an Engineer may become bored quickly and you will find them moving on soon. Also expect an Engineer to have a solid idea of how things should work to be effective. Do not expect to mold an Engineer – you should be hiring them to help evolve your team, not to persuade them to the way you do things now. Additionally an Engineer will be aware of the going pay rate for someone with their skill set, so do not expect to get them cheap.


Conclusion

Not all developers are created equal. When you have an open requisition for a new developer, be aware of what kind you are truly looking for. If you need an Engineer, but only have the budget for a Coder, you need to take a hard look at what the longer term implications for your team are if you don’t have the Engineer. Once you are in the interview, make sure you have questions set up to help you quickly determine what kind of developer you are talking to. And never forget what an unusual amount of influence the World Of Warcraft will have on your hiring decisions!

Do I really need to check for bugs in your code?

Posted in: Enterprise Java, Software Development Best Practices

An API is made up of not only code, but also documentation. Imagine the Java JDK without the associated JavaDocs – would it still be as popular or useful? Of course not. In fact without the provided documentation and JavaDoc tool to generate more documentation, the Java language probably would not have been anywhere near as successful as it is.

So while you can enforce many constraints and cover many issues at a code level, there are some issues that are better dealt with at the documentation level. We see comments like “if you pass ‘X’ to this method, the result is undefined”. Perfectly legitimate to say this if that is true of the nature of the code – mathematical algorithms are often dealt with this way.

But now that I have gone to the effort to say this about my method, what happens if someone does pass ‘X’ to my method? Do I need to handle that situation? Should I just throw an exception? If I do nothing, and my code fails gracefully or crashes horribly, is it a bug in my code?

I propose that in fact as a client, it is necessary to comply with the documented API just as much as you comply with the coded API.

Here is an example. Suppose, you are writing some code and you choose to make use of a class from the JDK core classes. You take a quick look at the JavaDocs to make sure you know what you are doing and off you go. You are an agilist so you also write a thorough set of unit tests and make an effort to cover edge cases and corner conditions. On one of these corner conditions you notice the test is failing. You look at the your logging output and see that the method you are calling from the JDK is throwing a runtime exception. You check the parameter values being passed using your favorite debugger and see that the value makes sense to you. You then go back to the JavaDocs and notice that it mentions something about certain values not being valid and that an undefined runtime exception is thrown when those values are passed. At this point you have a choice, change your code to work with the API or complain that the JDK has a bug in it. Of course you change your code – I am not saying there are not bugs in the JDK, but you should consider yourself unlucky if you actually stumble across one.

So if you are writing an API, go ahead and write code defensively, but don’t kill yourself to code against every possible asinine value someone might try to pass to you. If your code interface is designed nicely and you write good documentation and you write a comprehensive set of unit tests, as far as I am concerenced, you are pretty much off the hook. Don’t waste time and lines of code defending against obvious bugs in your client’s code. Besides, if you have enough time to write code to defend against bugs in other people’s code as well as your own, you are probably on a dead end project and are destined to be looking for work soon anyway.

I see this on a regular basis. Engineers who get caught up in the whole defensive coding idea, or test driven development. Not that either concept is bad, but when the first 30 lines of every method are sanity checks for parameters than you should maybe consider how you are spending your productive hours. And don’t get me started about when I see this in non-public methods – really, you can’t trust your own code to pass you the right values?