Have you noticed that Industry insiders like to invent their own language? You are following along in a fascinating conversation about some interesting aspect of something and just when it is all coming together and you can sense a real strong point being made, the speaker looses you completely on some strange term or phrase or, god forbid, acronym that they just assume everyone must grok*.
Aug
25
2009
Learn the Lingo – Domain names
Jul
23
2009
Another Interview with James Lindenbaum, CEO of Heroku – Part 2
Yesterday, we had part one of our interview with James Lindenbaum, CEO of Heroku, which provides hosting for Ruby on Rail applications. We had a great conversation with James, but there was a bit much for one post, so we divided the interview into 2. Here’s the second part of our interview….
Jul
22
2009
Another Interview with James Lindenbaum, CEO of Heroku – Part 1
Heroku (who we’ve covered here, here and here) provides provision-less hosting for Ruby applications, letting developers focus on developing. The hosting service allows developers to just push their code and it’s up in running – no worrying about running scripts, or setting up servers. Heroku recently came out of beta and now offers commercial, paid service. A few weeks ago, I had the chance to speak with Heroku’s CEO, James Lindenbaum, about their recent developments:
Jul
21
2009
The geeks give back to those that Give year round
Everyone in the auditorium knew when she stood up that this was going to be an interesting weekend. Sister Mary, dressed in a stark white Habit, stood out from the crowd of faded jeans, Converse low-tops and silk screened Tee shirts with ironic catch phrases like some lost Lawrence Welk fan at a Neko Case concert. But what she told the audience, how passionately she expressed her excitement for what was in essence just a new website, was nothing new by then. They had heard the same that night from a dozen other local charities and non-profits participating in GiveCamp 2009. Each charity started the weekend thanking the programmers and developers and designers for donating the next 48 hours of their lives to creating something for their own personal cause. So unaccustomed to this kind of appreciation for their unique gifts in this world, the audience of software and computer experts were overwhelmed to tears more than once. At least I was overwhelmed to tears at the opening ceremony, cresting at the pique of the emotional wave with Sister Mary shouting thanks to God that ‘The Geeks Are Coming!’
Apr
27
2009
Thoughts from KalamazooX Conference #kalx
I attended KalamazooX over the weekend, which was a great combination of design, business, and technical presentations. As someone who has transitioned from a programmer into marketing & strategy consulting, it was nice to see content that wasn’t just staring at code. I believe some of the slides are up online, but here are some thoughts, not from every presentation, but from some of my favorites:
Dave Giard – Effective Customer Communication
- Communications is a two-way street – both sides are responsible.
- It’s important to get/give feedback early and often.
- You need to add value for the customer – what does the customer feel adds value? – need to know this up front.
- Weekly status of what you did, what you plan to do next week, any issues/problems.
- A daily standup (including the client) is better.
- The most important part of verbal communications (any communications) is listening.
James Bender – Organizational Dynamics
- Plug into the company’s information highway (water cooler, wiki, blog, intranet, etc.).
- Be someone in the know.
- Evangelize yourself and your ideas (and also your team!).
- Build coalitions.
- Learn the right way to gripe.
Josh Holmes – The Art of Simplicity
- The definition of simplicity from Websters includes: lack of sophisitcation, good sense or intelligence – which is how technologists often think.
- Systems need to be designed so the user knows immediately what to do and starts doing it.
- A simple design does not mean that the problem solved was simple.
- Users may not see a request as complex – they just know it will make their experience better.
- Agile is a buzzword, but it’s what techs need to be in order to solve problems.
- The right solution is not the one other technologists understand – its the one the user does.
- Enterprise automatically adds ten times the complexity.
- Consumer space has solved bigger issues in simpler ways.
- We usually don’t understand who are users are – the top 3 things they do.
- Use the right tool for the job.
- Solving someone’s problem adds value.
Brian Prince – 5 Easy Ways to Be More Agile
- Be Subversive – start doing things without permission, without changing what you’re doing, help people see value.
- Stand up Meetings – what was done yesterday, doing today, roadblocks. Don’t solve problems – have speaking token.
- Keep – Stop – Start Meetings – Introspectives at end of each iteration. What should we keep doing, what needs to stop, what do we need to start doing – assign people to solve by next iteration.
- Must – Should – Could – Won’t Priorities (from user’s view). Keep quality and priority in the picture. Use quality in equation always.
- Keep users and client as close as possible (not usually the same). Ask – share – show. Tell stories. Use simple planning wall.
Leon Gersing – Change
- Make little changes until you don’t realize that you’ve changed.
- Be open to change.
- Know who you are.
- Don’t let others define who you are.
- There are 3 states in life – job, career, enjoying life – which are not always the same. Know which you’re in.
- Change where you work (not always the employer, but sometimes the environment, or your state of mind).
- If nothing ever changed, there would be no butterflies.
Technorati Tags: development, code, kalamazoox, code, coding, programming
Liked this post? Consider subscribing to our RSS feed or our weekly newsletter.
Apr
24
2009
Heroku Out of Beta – Fast, Easy & Cheap Ruby Hosting
Heroku, who we previously covered here and here, offers quick and easy Ruby hosting. Today their service came out of beta, with a commercial, paid version of it’s service. Web developers can focus on development, leaving deployment, hosting and scaling of the application to Heroku. Meant to provide affordable services which easily scale, packages start around $36/month. As the popularity of an application increase, Heroku can match demand, allowing developers to start small but scale up on the same platform.
Developers can customize their hosting by choosing database performance and size, http performance, and add-ons. Databases start with 5MB of storage for free and run up to 20 compute units and 2 TB of storage for $1600. Http performance, which Heroku calls dynos, representing one process of an application, and are priced by hour starting at 1 dyno for free and 40 dynos for $1.95/hour. There are recommended amounts of dynos for each type of database, starting at 2 for the smallest, free version. Add-ons include additional backups or crons (some are included), with wildcard domains and delayed jobs in beta, and memcaching, workling, and AMQP planned soon.
More coverage:
- Heroku to Exit Beta, Start Charging for Cloud Computing (GigaOM)
- Commerical Launch (Heroku)
Technorati Tags: heroku, rails, ruby on rails, ror, rails hosting, internet consulting
Liked this post? Consider subscribing to our RSS feed or our weekly newsletter.
Feb
27
2009
Scrum, Agile, Extreme – when programmers get ahold of a thesaurus.
Computer people just love to name things. The server guy who names all his machines after Star Wars characters competes with the network guy who names all his routers and switches after Star Trek characters to see who has the more obscure references. Usually the Desktop guy wins with his collection of Windows PCs named after Transformer characters, but that’s beside the point. It sounds like it is all in fun, but there is a very important reason we all do it. Technology is hard for humans to relate to. It is cold and lacks personality. Names help give definition to the undefined. They help give things context.
Programmers, being computer people, really get into the naming of languages and processes. I’d like to take this post to identify and briefly explain some of the terms you may have heard your programmers using.
Agile development
If San Francisco could be considered not just a place but a lifestyle, Agile development would have a similar vibe in the programming world. Typically it refers to the 12 guidelines people in software teams follow when working together on software projects, though there are widely different ways to actually put those guidelines into practice. The ideal behind an Agile development team is that it is small, it meets all the time with each other and with the clients, and it writes code in small chunks that the customer sees working every couple weeks. Agile was a reaction to the inflexibility of older programming procedures that didn’t allow the customer any flexibility to change their mind late in the delivery cycle. Since customers are constantly rethinking their needs, Agile was developed to allow the code to change with the requirements. Below are the 12 principals of the Agile Manifesto.
- Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
- Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
- Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
- Business people and developers must work together daily throughout the project.
- Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
- The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
- Working software is the primary measure of progress.
- Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
- Continuous attention to technical excellence and good design enhances agility.
- Simplicity–the art of maximizing the amount of work not done–is essential.
- The best architectures, requirements, and designs emerge from self-organizing teams.
- At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
Scrum
HR, Sales and Accounting may have meetings, but only programmers can take the basic idea of getting together in the same room and rename it a ‘scrum’. Borrowed from the term used to describe a huddle in rugby, a scrum is a highly organized, short daily meeting of all people involved in an agile project. It has the singular goal of keeping people focused on the project, which is really important since a ‘sprint’, or stretch of time allotted to write working code, is usually only two weeks. Guidelines for scrums can sound harsh, only three questions are asked, everyone should remain standing, only people with a stake in the project should speak, but it was invented in direct contrast to pointless time-wasting mega-meetings that the Dilbert comic made an empire satirizing.
Extreme Programming & Test Driven Development
Who wouldn’t want to work on an something with the word ‘Extreme’ in it, huh? Extreme Programming (XP) is very similar to Agile, or it might be more accurate to say that it is a good case study of Agile programming before there was such a term. The real big take home from XP that sets it apart is its absolute devotion to the idea of testing. Now, as a lil programmer, I thought testing code was for suckers who worked government jobs. Then I was turned onto the wonders to full stack testing and how it changed my whole outlook on my craft. Testing is really the only way to write Enterprise ready code. Some guys saw that if you wrote your tests first, then wrote code that made the tests pass, your applications would have fewer bugs. They called it Test Driven Development (TDD). Turns out testing is becoming the rock star of the programming world thanks to web frameworks like Ruby on Rails and Symfony having it baked into the package.
This post just scratched the surface of the terms programmers (and computer people) love to throw around. If you know of a term that you want a little help with, add it down in the comments and I’ll try to reshape it into something that hopefully makes more sense. I’ve been known to use puppets with clients before, so anything’s possible
photo attributed to Foxtongue
Feb
26
2009
What were they expecting?
Succeed at managing your customers expectation and you can never fail. Fail to manage your customers expectations and you can never succeed. ~ me
This is one of my all time favorite universal lessons I have gleaned from business. There isn’t really any part of my life that involves other people which doesn’t benefit from the practiced art of managing the expectations of those I’m interacting with. When another human knows exactly what they can expect from you, on your terms, and when you consistently meet or beat that expectation on their terms, you have set the stage for a powerful ally in business; trust.
The reason this is so important is because people on a whole are very self-referential, which means they see their own perceptions and actions within the conversations and interactions they have with other people. Imagine two people talking business over lunch. The speaker could say ‘it will be a short project that we can deliver with limited resources and for a reasonable amount of money’. The listener will build context around the statements with their own assumptions, drawn from their own experiences of what is short, limited and reasonable, that will ultimately create very different picture than the speaker meant to convey. At that moment, an expectation was set in the mind of the client that may or may not be ironed out in the contract negotiations but will greatly influence the customers satisfaction when the project is completed.
I worked with a fantastic colleague on the team that had a very bad habit of responding to challenging technical requests with an automatic ‘Not sure yet, but that should be doable’. What he meant to deliver was ‘It SHOULD be doable, but of course I won’t know until I work on it” and what the customer heard was “That WILL be EASY and there is no reason it won’t be done on time”. So when said colleague moved heaven and earth to deliver on what turned out to be a very difficult task, the customer was unimpressed. They had already expected it to be done without effort and was maybe a little disappointed that the colleague didn’t work on some of the other, less important features. This is what I would call a ‘Technical win and an Expectation fail‘
Here are some tools and tricks I use when working with other people to help set the expectation
- Pictures and mockups. When you are working in the web industry, their really isn’t an excuse to not mockup what you are seeing in your mind for the customer. A tool I like to use is Balsamiq, which is a Flash based web mockup framework that is quick and easy to use
- Agile Development. The agile process focuses on rapid delivery of code, typically every two weeks, that gives the customer something to wrap their head around. I think Ill do a full post on agile tomorrow
- Closing summaries. When I talk with customers, I have developed a technique of always closing out a conversation by saying ‘So, what I understand you want is…’ and just re-summing everything you’ve been talking about. Etiquette might frown on dragging on a conversation past what the listener wants to endure, but I almost always find mismatching expectations in the closing summaries.
What do you do to manage someone’s expectations?
photo attributed to polandeze
Technorati tags: software, software development, software management, agile, agile development, customer-centric, customer service
Feb
11
2009
JSON and the Argonauts
The Greeks sure were fond of super-hero team titles. There was Jason, commander of the Argo and her crew of the best of the best, pitted against irresistible forces beyond moral man’s endurance. What does this have to do with JSON, the JavaScript Object Notation standard used by the web 2.0′s best of the best of overcome an accent foe called Same Origin Policy? Can’t think of a thing, I just really liked the title.
A funny thing happened on the way to the Mashup. I’m sure someone somewhere, maybe even here, told you that RSS feeds were going to revolutionize the way we distribute information. We were all so right in so many ways because RSS, or ATOM if you prefer, has opened up the world to the unimagined possibilities available online. Think of some way that you want to consume information. Go ahead, I’ll wait. Ok, you are all right you can consume information that way. Oh, heh, I mean almost all of you are right. That guy in the back with the Helvetica shirt in Metalica font, I’m sorry but we can’t help you with your idea. Thing is, as much as you may want to have a single page that can then pull and update XML based RSS feeds from any site in the world from within the browser without refreshing, you’re not allowed. It is for your own protection actually. We call it the Same Origin Policy.
Here is the idea. When your web browser pulls down a web page’s code from a modern site, it is usually pulling down a collection of HTML, Stylesheets, Javascript. That HTML tells the page what content goes where and what images to place by the content. The Stylesheet (CSS) tells the browser how to make that content look and how to make it act on the page. Then the Javascript is there to give the page life, make it interact with events, make it do impressive things that we have come to love and cherrish. In the AJAX world, those impressive things involve grabbing information from the server and updating the page without screen refresh. Javascript is nye omnipotent in the browser, and yet there are some quantum limitations built into the works. Beyond the sandboxing of JS, there is one little design decision from Netscape 2.0 that has totally altered the web 2.0 landscape. Netscape decided that a browser would only allow scripts to interact with domains that the page came from. If a page is loaded from www.bobsdiscountlasers.com then AJAX calls are limited to bobsdiscountlasers.com. The grand illumination of mashups, where data flows from many different locations onto one page in a relevant way, almost never happened because of this.
Web browsers weren’t designed with mashups in mind, and ‘the warts have been there from day one’, [David Boloker, cofounder of the OpenAjax Alliance and IBM's CTO of Emerging Internet Technologies] says. Browsers contain a security feature called the same-origin policy that’s meant to keep malicious code hosted on one site from grabbing data, such as stored credentials, off another site. The same-origin policy prevents websites from one domain from requesting data belonging to another domain. ~ Security services and Mashups
But, of course, Mashups do exist. We see Google Maps on thousands of pages not under the google.com domain. How is it done? We’ll get to the hero of the day in a second, for now lets look at other popular workarounds
- Mashup at the Server Side: Since the JS limitation is browser based, you could do all of your mashups at the server. The server could serve as the collector of the different sources of information, combine them intellegently and cache the results. At best this idea is inconvenient because it adds layers where they need not normally be. At worst this does not scale when you have a single location for distributed information
- Flash/Flex: The Flash VM doesn’t have the Cross Domain limitation that plagues JavaScript. A file on the server gives a list of permitted sites that the Flex app can pull data from. I have talked with Adobe Evangalists about this option and they seemed to hint that this design decision was intented to hit javascript where it was weakest.
- AJAX Proxy. Similar to the first method, a proxy allows the client to pull the information through it. It isn’t stored on the proxy, though it can be cached, and no combination is done. Again, this is a scaling issue
Stop passing code, start passing data. What all of these work arounds do is bypass the security concern with Same Origin Policy (SOP). SOP was originally intended to combat early attempts at Cross Site Scripting (XSS). Modern XSS has a nasty list of exploits that I don’t have time for here, but one way to think about it is this: If you let Javascript pull code from untrustworthy places you are inviting problems. One possible approach to this issue was to stop the push and pull of code but to allow the pushing and pulling raw data. That is what JSON is, a way to encode data to be pushed and pulled using AJAX calls. Though the X in AJAX stands for XML, AJAX really is more often using JSON because SOP will allow it to be used cross-domain. So with JSON you can pull in Google Maps and that list of Micro Brewerys right in the browser, Mash them up using Javascript, and asyncroniously keep the data refreshed, the app reactive, and your buzz in good spirits (You are walking to these pubs, right?)
My prediction; RSS feeds are going to move away from XML and on to JSON in the future. Or at minimum, support both. John Resig, the creator of jQuery, even has a converter to get us all started.
Photo attributed to jasonr611
Technorati tags: software, json, javascript, javascript object notation, rss, atom, xml, mashup, web development, code
Feb
04
2009
For 'Bleeding Edge' prepare to pay in blood
If you are in software development, take a good hard look at the code you are writing right now. If the string of Roman characters resemble Java or .Net or C/C++ then I have some wonderfully awful predictions about the next ten years of your life; That language is your scarlet letter and will follow/define you for the next two jobs you end up accepting. That sounds bad but you are the blessed among the damned – You can and will find that next job. For Bleeding Edgers, the road is not so well paved.
In my last job I was a Bleeding Edger. You know one if you work with one, always looking at the latest release of the newest language to see if it has a better solution to your particular problem. In my case as a Software Manager, being a Bleeding Edger meant an obsession with ROI in our software solutions. Links to anything that could trim development time and/or expense filled my Delicious feed. I pushed my team to move beyond Java’s heavy web frameworks and to adopt Rails as a rapid application prototyping framework. We cranked out good, solid software solutions 4 times faster than our java days and I was happy. When a project came along that could use Flash, we wrote it in Flex instead because knowing how this company worked, they’d want a desktop and an offline version in the future. A year later we were cross compiling the Flex code into an AIR application and saving a tremendous amount of time, and we were happy.
But being a Bleeding Edger means there will be dark days to contrast the brilliantly sunny ones. Our ROI figures were not enough to protect all of us throughout this economic upheaval and some would have to make the sacrifice for the rest. I would like to say that, as the manager, I fell on my sword for them but that’s not really the case. The decision never reached my level. I was the highest compensated on the team and so I was killed by simple, cold math. The blood spilled that day is still dripping. It still hurts.
The software job market is a rigged system. Heavyweights in the market put enough momentum behind enough Java and .Net and C/C++ projects that they can be considered perpetual motion machines. A class hierarchy between Java and .Net, perpetuated by recruiters with a simple word match on a job board, stacks the deck against the Bleeding Edgers in the mainstream. You are a Hatfield or you are a McCoy or you are an innocent bystander likely to get shot in the crossfire. The mainstream is not a system able to help the Bleeding Edger. Sure, there will be the occasional posting that isn’t in your location and is looking for some bizarrely specific, must have requirement that categorically eliminates all humans including the guy who originally wrote the book on the library they are using. In the end, Bleeding Edgers need to work outside of the system.
For the young, there are no unemployed Bleeding Edgers only uncompensated open source code contributors. If you have the ability to live on nearly nothing, working outside the system can be a very rewarding and ultimately fulfilling life choice. For the responsibility burdened older generations, there are really only two options as a Bleeding Edger. The first, and likely most chosen, is to re-assimilate into the collective; scrub your resume of all references to Ruby and Jython, and Grail, prop up your sun certifications if you have them, and become a team player. The rest of us Bleeding Edgers, the ones the economy hasn’t driven to ditch digging, will become the countries next batch of serial startup founders. We will be easy to spot, just look for the scars.
Technorati Tags: code, ruby on rails, ROR, software, software management, software development, web development
Digital Marketing & Strategy
Connect with Sazbean