/** * Declares that this test can be run as a JUnit test, and does not require * the trappings of running as an Eclipse plug-in test. */ @Retention(RetentionPolicy.RUNTIME) @Target({ElementType.TYPE, ElementType.METHOD}) public @interface RunAsJUnitTest { }
/**Nobody likes running tests in the plug-in container if he or she doesn't have to. Surely, I'd much rather run nice fast JUnit tests, particularly when I've separated out code specifically for fast unit tests.
* Declares that this test must be run as a plug-in test.
*/
@Retention(RetentionPolicy.RUNTIME)
@Target({ElementType.TYPE, ElementType.METHOD})
public @interface RunAsPluginTest {
}
"Attendees must be an employee or contractor of an "Enterprise User" of Eclipse technology. Enterprise users typically are responsible for the use of Eclipse by hundreds and even thousands of developers in their organizations."Are you planning to attend this conference? Let me know.
Thursday, August 26, 2010Mr. Grumpy: Grump. Nobody interesting is presenting.
9:00am - 5:00pm
And it's at the Googleplex!
Apprenticeship Patterns cataloges dozens of behavior patterns to help you perfect essential aspects of your craft. Compiled from years of research, many interviews, and feedback from O'Reilly's online forum, these patterns address difficult situations that programmers, administrators, and DBAs face every day. [ref]As is typical with patterns books, much of the information will have an "I already knew that" feel about it, but it's pattern books aren't about learning new information, they're about unlocking information already in your mind. In this particular case, Apprenticeship Patterns is written as a useful text for new engineers. This comes from the Goals section:
We have written this book in order to share solutions to the dilemmas that are often faced by inexperienced software developers. We’re not referring to technical dilemmas; you’re not going to find any Java design patterns or Ruby on Rails recipes in this book. Rather, the dilemmas that we focus on are more personal, concerning your motivation and morale. This book should help you through the tough decisions that you face as a newcomer to the field of professional software development.I had the honor of reviewing this book and providing feedback to the authors prior to its publication. So, I think their goals are a bit misleading. I'm a very experienced engineer, and I repeatedly found ideas and inspiration from it. It's not a very long book, it's easy to read, and I think it's ideal for professional reflection. I've recommended this book to several people, and those that have read it have had very positive experiences.
Just like we were one of the first O'Reilly books to experiment with using a wiki to get early feedback during the writing process we're also one of the first O'Reilly books to experiment with publishing our material under a Creative Commons license. Starting from today the book is now available here: http://apprenticeship-patterns.labs.oreilly.com/How exciting! Now this book will become the next one I review in a reading group.
I love tutorial sessions. Working with OSGi: The stuff you need to know finally convinced me that services have a place in my bag of tricks, particularly because they explained that ServiceTracker is as evil as I thought it was. (Go declarative services!)
Keynote: Rocket Science and the Republic: Jeff Norris' keynote was the only one I missed. It was the morning after my talk, and I celebrated that night just a little too much and opted to sleep through the talk. Ian Skerrett called it the best keynote ever
Keynote: Software Professionalism and the Art of Saying "No" by Uncle Bob Martin. What a great presenter. I took some good notes, and was left with all sorts of ideas. Those notes are published as a separate post.
Eclipse in the Enterprise: Lessons from Google
Providing Eclipse tools to thousands of engineers at Google is a satisfying job, but it's not always easy. In the last two years supporting Eclipse at Google has gone from casual support by enthusiasts in their spare time to a dedicated team mandated to make engineers' lives better. We will talk about the plug-ins we've written and processes we've established to provide features, enterprise deployment and support, and even share some of the pitfalls discovered along the way.And then, come to the Eclipse In The Enterprise BoF on Tuesday at 7:15PM for an opportunity to discuss how Eclipse is used at your organization!
Hey, you! Yes, you -- don't you work for that big company? Are you supporting hundreds, maybe thousands of your Eclipse-using colleagues? Are upgrades and environmental consistency your problem, too? Are you constantly struggling with fitting your company's build system to the IDE and Eclipse builders? Is your source code base so large that you're continually fooling Eclipse into thinking it's smaller?
Then come meet your peeps at the "Eclipse in the Enterprise" BoF. Let's share war stories and ideas. Impress everyone with your clever solutions and work-arounds! We're all facing the same issues, so come, let's talk.
The prototype took five hours to write: one hour to parse and codify the data, one hour for figuring out how to get reasonable coordinates for each address, and three hours to get my head around Javascript. For me, writing Javascript is like this: trial, error, trial, error, google, trial, trial, error, trial, error, google, but by the end, I got a map that showed all the jitney stops and their paths.
(This is a great time to point out that I think that GWT is magic, and the GWT team are a bunch of magicians.)
 |  |
Before | After |
