Blog FeedI went to Java One last week and was a bit surprised by the amount of cloud chatter. I expected to hear a lot about Larry Ellison and Scott McNealy on stage together. I expected melancholy predictions that this would be the last Java One. I did not expect to hear everyone talking about cloud computing. Don’t get me wrong, I knew that Sun was going to talk about cloud computing. The Sun booth had several stations dedicated to the subject and the Sun store was selling cloud t-shirts. The thing that got me was how many participants were talking about the cloud. All of the technical sessions that had anything to do with cloud computing were packed. Even more surprising was the fact that the sessions extolled the virtues of Amazon EC2 even though Sun is working on their own Cloud offering. I sat through three sessions where the first half hour was dedicated to “Amazon 101”. It looks like Amazon is where real solutions are being created for now but there is definitely competition on the way.
-
Options
The “last mile” – It often seems like 10
June 2, 2009 — Erin CurtisIn the software development lifecycle the results need to ultimately get out into production. The application must make it onto the server, the server needs to be configured and all of the properties, paths and settings need to be correct to get the value of the application. Those in the data center often refer this to the last mile. And it is often a real bear. Seems more like 10 miles at times. Sophisticated and robust tools like ElectricCommander have automated almost all of the steps in the process, but rely on home-grown scripts to lay the applications down on app servers. Why? It is actually a logical approach if you have no alternative. Every environment is different. Every app has different settings for WebSphere (or WebLogic or JBoss) and there is no way to anticipate those differences. Therefore – the last mile is unique to each customer and each app –the IT or dev teams write scripts. It takes skilled resources and the scripts are always in need of attention. Not anymore. STOP. That is no longer necessary. What if ElectricCommander could hand off the EAR file to a software tool that has already pre-built a model of the environment and has made all of the JDBC, JMS, and application bindings for you? What if it required NO scripting? What if the “last mile” was now automated and under the control of your build and release system? Ta Da ! It is now. Phurnace Software is an auto deployment and configuration tool that will eliminate custom scripting. And you can drive it all from within ElectricCommander. The last mile is now just a step away.
- Daniel Nelson, VP of Products, Phurnace Software
JavaOne 2009
June 1, 2009 — Erin CurtisPlanning to head to JavaOne this week? Stop by our booth in the Expo Hall and say hello. We’ll have product experts on hand to show you our latest and greatest solutions for Java development. Come see us at booth #304.
Annocat: e pluribus unum
May 27, 2009 — Eric MelskiElectricAccelerator annotation files are a fantastic way to get a grip on your build behavior and performance, but what if your Build (capital B) spans more than one invocation of emake? Annotation gives you a good look inside any single invocation, but there’s no way to get an overview of the entire process. You can’t just catenate the annotation files from subsequent emake runs — the result won’t be well-formed XML, and the timing information for jobs in each subsection of the build will reflect time from the start of that subsection, not from the start of the logical build. Plus, you run the risk of having overlapping job identifiers in different subsections. What you need is a specialized version of cat that is annotation-aware. In this article I’ll introduce annocat, a simple Perl script I wrote for just this purpose, and I’ll explain how it works.
Read the rest of this entry »
Just a minute!
May 8, 2009 — Scott Castle
How much is 'Compiling' costing you? (image xkcd)
Yet, by far the most expensive cost in software development is probably slacking off in the hallways, waiting for code to compile. Joel Spolsky – who writes the JoelOnSoftware blog, and manages the dev team at Fog Creek Software, recently wrote about his quest to shorten a thirty-second compile for the developers on his team. Thirty seconds! I have a hard time getting engineering managers to think about improving thirty-minute builds; reducing a thirty-second cycle time feels like an awfully small gain. Read the rest of this entry »
Delta: the coolest tool you’ve never heard of
May 5, 2009 — Eric MelskiOne of the challenges that any developer faces is finding a small test case that reproduces a defect reported by users. That’s often easier said than done: when the defect originally shows up during parsing of a makefile consisting of 20,000 lines of nested calls to $(eval), separating the interesting lines from the irrelevant lines can seem like an exercise in futility. Thankfully, you don’t have to do it alone. Some clever guys at UC Berkeley wrote a tool called delta to assist with just this problem. In this post I’ll show you how you can use delta to distill useful test cases out of otherwise intractable inputs. The example involves makefiles of course, but the tool and the techniques are useful to developers and QA engineers in all fields.
Read the rest of this entry »
Enabling Agile Software Development
April 30, 2009 — Dax FarhangAgile is great. It seems that everyone is either adopting or talking about it (of course many of those will probably be perpetually adopting and talking). However not everyone is succeeding with Agile. One reason is that in order for Agile to work well you need highly experienced developers that are familiar with a broad range of skills and the processes involved in software development. These developers (often the most experienced) are in high demand and short supply. So what can be done to help ensure that your Agile team is successful even with fewer highly experience developers? Use tools to export the highly specialized knowledge that those developers bring to the table, and to bridge the gap between the most and least experienced developers on your team.
Do more (computing) with less (hardware) (people) (money)
April 22, 2009 — martinvrImagine if you discovered your colleagues only work 4 hours a day. You thought everyone was working as hard as you until you started monitoring what they did all day. To your surprise, many of them were idle for hours at a time, just sitting still waiting for someone to give them work. And when they did work it was in 10 minute bursts separated by more waiting around. I think you would be upset if this were true. You should only get a full day’s pay if you do a full day’s work, right?
Read the rest of this entry »
Using ElectricCommander to Parallelize Build and Test Processes
April 14, 2009 — Anders WallgrenWhen we talk about parallel builds at Electric Cloud, we’re most likely to be talking about ElectricAccelerator, which does an awesome job of speeding up builds automatically, giving 10-20x speedups on a regular basis. We sometimes forget to mention that ElectricCommander can also be used to parallelize build processes, with a very small amount of work.
Makefile performance: pattern-specific variables
April 13, 2009 — Eric MelskiIf you’ve been using GNU make for some time, you are probably familiar with both pattern rules and target-specific variables. You may even be familiar with the intersection of these features: pattern-specific variables. But you may not be aware of a subtle change in gmake 3.81 which affects the processing of pattern-specific variables with potentially disastrous performance consequences.
