Twitter github

Category “work”

Eclipse, Remote Systems and Shells

I had a colleague ping me today saying that he likes Eclipse but wished there was some terminal access inside of Eclipse (he’s a Linux guy). I told him I had a solution via the Target Management (TM) project at Eclipse. In essence, the TM project creates data models and frameworks to configure and manage remote (mainframe down to embedded) systems, their connections, and their services. While that sounds all great, let me just dive into what TM offers that most people would find useful.

First, to fulfill my colleague’s request of opening a local shell in Eclipse, TM handles that well (you should start with the Remote System Explorer perspective), simply open the Remote Systems view and right click on the Local Shells item to open a shell as shown below.

On top of local access, TM can even do better and give you access to remote systems. For example, I find myself hacking on build.eclipse.org a lot and the ability to seamlessly open a shell, browse the file system and edit files is priceless…

Did you know about TM and the remote system capabilities? I believe TM is one of those hidden gems in Eclipse.

Easier Access to the OSGi Console

In Eclipse 3.6 M7, it will be easier to access the OSGi Console within the running Eclipse. The Equinox team added a org.eclipse.osgi.framework.console.ConsoleSession service that you can use to get the input and output to a console session. The PDE team took advantage of this recently by extending the org.eclipse.ui.console.consoleFactories extension point and allowing you to bring up the OSGi console easily…

This was feature was really put in for some members of the Equinox team but thank you to Dave Carver for encouraging me to blog about it so other people would know about.

Speaking at Texas Linux Fest 2010

Next weekend, I’ll be speaking at Texas Linux Fest 2010 which happens to take place in my beautiful town of Austin, Texas…

In a theme similar to what I blogged about a couple days ago about getting involved with open source, I plan to give a talk entitled Open Source from the Trenches: How to Get Involved with Open Source and Be Successful. It’s a long drawn out title, but the basic gist of it is that I have 25 minutes to share my experience in open source land with the audience. I’ve learned a lot from everyone I have met a long the way and plan to divulge some of the lessons learned. I’ll admit I’m a bit nervous as I have never given this type of talk before…

For those from the Eclipse community, anything else you want me to say that you may have learned a long the way? I think we have a special place in the open source community as we tend to dance between the line of commercial and open source really well compared to other open source communities. I was going to say “dance with the devil” but that would be very freetard of me, I’m more pragmatic these days 😉

Anyways, if you’re in the Texas area, I highly recommend attending the conference. I’m personally looking forward to these talks:

I hope to see people there. If you’re in the area and want to meet for frosty beverages, let me know. On top of that, we Red Hatters also plan to have a lot of Fedora swag at the event too (I’ll have Eclipse stickers).

IDEs are like cockpits?

According to this article, Integrated Development Environments (IDE) are like cockpits…

I kind of agree, except my IDE doesn’t have missiles (yet)…

Now, at last, hardware design teams can use Eclipse as a basis for their own customized IDEs, based on the commercial and open-source plugins that they need in their central cockpit for hardware design.

During dogfights (one-on-one acrobatic fights), a fighter jet pilot needs to keep his attention focused on the enemy aircraft. He cannot afford to keep looking down at his dashboard in order to check his weaponry status. Instead, he uses what is known as a Head-Up Display (HUD). This display consists of a transparent screen through which the pilot looks at his opponent. At the same time, the HUD projects extra information like air speed and altitude on the screen. This way, the pilot can keep his head up and remain looking at the surrounding environment, while still keeping track of critical data.

A HUD is not a substitute for pilot skills, but it enhances the pilot’s capabilities to levels that are unreachable without this technological support.

Software engineers, like hardware designers, continuously work with code, documentation, build scripts, and logs. What can they use as their cockpit?

I kind of like the analogy of having a central console (and missiles). I don’t like the analogy in the sense that a cockpit also implies complexity. I think that IDEs aim to simplify people’s workflows instead of making the more complex. The only thing complex is the initial learning curve required to learn the instruments. What do you think?

Anyways, give the article a read… it talks about the success of Eclipse in the embedded software development space and how Eclipse is now being used in hardware design due to Sigasi (a startup that focuses on Eclipse-based VHDL tools). I actually met the Sigasi folks in person at the last Eclipse Summit Europe and we went for a nice jog around Ludwigsburg. Small world, eh?

I can only wish them success as the Eclipse ecosystem is all about supporting companies like this.

The Death of the Floppy Save Icon?

Bill Higgins filed an amusing bug today about stop using the floppy disk icon to represent saving things in Eclipse-land. I guess I’ve been doing computers for awhile that the thought never crossed my mind until today. I mean, floppy discs aren’t used by modern computers anymore and I’m pretty sure kids coming into college these days aren’t aware of what they really are besides the basics. I guess a similar analogy here is the difference between 8-track tapes and compact discs. But what else would you replace the icon with? A fluffy cloud?

Kids are all about saving things to the cloud these days. Just chuck it in a BigTable and it’s alright.

What do you think? Never forget?

On a side note, I know can’t get that Don’t Copy That Floppy song out of my head. Thanks guys.

OSGi and Lotus Domino?

Looks like some people are exposing OSGi on Lotus Domino servers.

I especially like the part when they mention the benefits of extensibility, easy deployment and leveraging existing OSGi assets. Oh, the mention that they get “better tooling with Eclipse IDE and its first class Java and plugins editors and Java debugger” is a nice touch too. In all seriousness, the more OSGi gets exposed in the significantly large Lotus ecosystem the better.

Apply now for Google Summer of Code at Eclipse

This is time given my Getting Involved with Open Source post. Google has announced that students may apply for the Google Summer of Code (GSOC) program today.

If you’re a student, get on it and start talking to the open source projects you’re interested in. At Eclipse.org, check out our list of project ideas and the people to talk to if you’re interested. I recommend you start talking to potential mentors soon as they will be the ones reviewing proposals in a few week and scoring them.

As for Eclipse.org projects, how about we put some more projects ideas on the wiki? I’m a bad sad I see nothing from the e4 project there… it would be a great way to get some work done over the summer and attract new contributors.

Getting Involved with Open Source?

I was recently approached by a student I mentored a couple years ago. He’s been doing some job shopping and asked for some advice on how to get involved with open source and be successful at it. At first I thought, I’m naive what the heck do I know… I was shooting for a simple answer but after a few minutes of thinking about it I was a bit lost what to say. I rather not offer some trite advice and leave the guy with nothing practical. After spending some time over the weekend thinking about it, I started writing and came up with this short bit of advice…

Find your passion. Contribute to it. Brand yourself.

What do I mean about finding your passion? There are a ton of open source projects out there that span all sorts of topics. Find open source projects that truly interest you and are exciting. If you don’t, you’ll soon find yourself distracted with other things. Someone once said that, “Nothing great in the world has been accomplished without passion.” Also note that the majority of open source communities are meritocracies and to build a repertoire with them takes time. If you really want to get involved with an open source project and potentially become a committer you need to dedicate some time. So that being said, there’s some practical things we can do to help your passion to get involved with open source.

Find the Right Open Source Projects

Like I mentioned before, find open source projects that interest you. There are a lot of forges out there you can browse for interesting work, like SF.net or GitHub. However, I recommend that you take a look at the list of mentoring organizations from the Google Summer of Code (GSOC) program. These organizations have already been vetted by the GSOC organizers and are of a higher quality than other open source projects out there. They also tend to be more welcoming to new contributors which brings me to my next point about mentors.

Mentors, Mentors, Mentors

I believe mentoring is crucial to your success in becoming involved with an open source project. Without a mentor, you will waste time learning the ropes of the project. There are a lot (but not many) of open source projects out there that have formal mentoring programs. For example, the Fedora project has a program where you can find mentors. The Eclipse project also has a specific place contributors can go if they are seeking some mentorship. Another approach that worked for me a long time ago was simple emailing a project leader and asking him if they were willing to mentor me. Sure some people will say no, but you’ll be surprised on how many people say yes. Oddly enough, this is how I got involved with Eclipse.org but that’s another story.

If you qualify as a student, I think the Google Summer of Code program is one of the best ways to get involved with open source. I have mentored students the past few years with GSOC for Eclipse.org and have seen some amazing things happening. I’ve seen students evolve from open source contributors to full-fledged developers. I have even seen a couple students find open source related jobs due to their involvement in the program.

Contribute

Many open source projects are meritocracies. In order to get involved, you have to contribute and build your repertoire. So simply do the work in finding some bugs you can fix. This is hopefully where your mentor can come in and point you to some low hanging fruit to get you started. Since I’m a software guy, I have a tendency to focus on programmers but there are many ways to contribute to open source outside of code. For example, documentation and testing are ways you can get involved with open source. For example, I think the Fedora project does a good job in highlighting the different avenues you can contribute to the project based on your skillset and desires.

If you’re into books, I can recommend Karl Fogel’s Producing Open Source Software as a good read. It’s a little outdated in my opinion, but can give you some insight on how a lot of open source projects operate. It may also be useful to you if you start an open source project in the future of your own.

I also recommend getting an Ohloh.net account so you can track your code contributions. For example, I’m able to look at my Ohloh account and remember the good ol’ days when I actually contributed to Gentoo Linux.

Brand Yourself

This may be odd to hear for developers, but you are a brand and you should control your image. In open source land, things are done in the open so we have to be mindful about that. Avoid negativity at all costs and kill people with kindness. Be critical without being negative, it’s possible. Also, if no one can find you, how can you expect to be successful in an environment that is all about being open? So I recommend getting yourself a website, a blog and a Twitter account. These things will help with visibility and will also get you in the mindset of doing things in the open. It will also allow you to share your expertise in the areas that you’re passionate about it. When you’re comfortable, I would also exude confidence but wouldn’t over do it.

I would also recommend getting a slideshare account if you’re giving talks at conferences. I use it as a dumping ground for all my presentations in the hopes that people may find them useful.

In the end, the point is that you have to understand you’re a brand and if you want to help your career, you should be findable. Also in terms of career advice, I say that you should brand yourself for the career you want, not the job you currently have.

Networking

Networking is one of the most important things you can do for yourself and your career. If you can, attend conferences (including other type of meetups) and meet the people you have been working with (or want to work with) in a face-to-face environment. There’s no better way to connect to folks than sharing a frosty beverage and chatting it up.

On top of conferences, do yourself a favor and get a LinkedIn account. This will help you establish a professional network and also may help you land a open source related job in the future if that’s what you want.

In the end, my advice is to build a network via conferences and online interactions.

Conclusion

Well, that’s all I have for my brain dump about getting involved with open source and being successful. I really just kept writing and put what sprang into my mind, so sorry if it’s a bit hectic. In the end, I think it’s all about finding the right open source community to act as an outlet for your passion. Anyways, I hope people find it useful as I’m not sure what other advice to really give. What do other people think? What helped you get involved with open source? What could have done better? What helped you become successful?

Speaking at GeeCon 2010

I have the honor to speak at GeeCon 2010 later this year which will take place in Poznan, Poland.

I will be giving an Introduction to EclipseRT, Equinox and OSGi.

There’s a lot of exciting things happening around EclipseRT withing the Eclipse community and I hope to spread that love in Poland. If you’re not too far away from Poznan, I highly recommend attending GeeCon as the list of speakers is fantastic.

On a side note, I’m excited for a chance to visit Poland again as Polish is my native tongue and I’ve been out of practice for awhile. Furthermore, I’m looking forward to having some frosty piwo’s with the locals.

EclipseCon 2010 – Understanding Git at Eclipse

Yesterday, Shawn Pearce (Google), Robin Rosenberg (Dewire) and Matthias Sohn (SAP) and I gave a talk at Eclipse about Understanding and Using Git at Eclipse.

I believe the tutorial was well received. Our goal was to introduce people to Git, JGit and EGit. We also talked about why Eclipse is moving to Git in the future. I believe we accomplished that on top of the message that there’s no free lunch to moving to Git at Eclipse. Heck, I don’t only want Eclipse to move to Git, I want other open source projects to do it. The license of JGit is liberal enough that other projects like Netbeans can embed it. Git simply empowers contributors in a way that’s not possible with centralized version control systems.

It will take time to get the tooling right and understand how much a distributed version control system like Git is the perfect fit for Eclipse. On top of that, we explained how the EGit and JGit projects leverage Gerrit to facilitate contributions and code reviews.

It’s my hope by the next Eclipse simultaneous release, we have a good amount of projects moved to Git and the tooling is top notch. The only way this will happen is if we admit to ourselves there’s no free lunch and provide feedback. I’m already impressed with what happened after the tutorial… we have people filing bugs and providing patches. This is what open source is all about.

If you still don’t get it, watch Linus’ tech talk about Git and read the Pro Git book.