Our dependence on search technology grows.
A while back, I posted the Top Ten Ways to Say Eclipse. It seems like every few days, I get a new one to add to my list. I get asked about Eclipse cables, Eclipse wire strippers, Eclipse massages, and more. The variety is inspirational.
Most of the people who contact me are pleasant enough. Some acknowledge that they’ve probably contacted the wrong person. Some people are downright nasty. Again, the variety is inspirational.
I’d wager that all of these misdirected missives, are the result of the sender simply typing the name of whatever it is that’s itching them into their favourite browser, clicking the first thing in the list, and navigating our contact links until they find the most promising email address. The eclipse.org pages do pretty well in terms of page ranking on Google, so we’re probably the first hit for anything “eclipse”, and once you get that first hook, it’s only two clicks to the “General inquiries” (EMO) email address.
Oh well… I guess that it only takes a few seconds for me to explain that we’re not the eclipse they’re looking for…
The question I aim to help answer is this: how do I get the skills I need to get an entry-level job that already requires the skills I need?
I have noticed recently from several of my in-town colleagues in the software business that there seems to be a shortage of qualified, interested people seeking open positions. The key word here being “qualified”, with “interested” not being far behind. There is no shortage of applicants, but it seems like well more than half are so unqualified that they are job-seeking for the sake of job-seeking, yet not actually looking for a place to work in return for a paycheck. I know in the minds of many people there is an apparent unsolvable problem where you cannot find a job because you do not have the skills, but cannot get those skills because you can only learn them while on that sort of job. My aim here is to explain what skills those are and how you might go about acquiring them without having true, full-time, paid job experience. Please note that these comments are my own opinion and not those of guidance counselors, hiring managers, or others that are far more in-the-know than I am.
Even before addressing skills, however, there is something to be said about the non-technical parts. Number one is to do a little research. Find out something about the organization you are joining. What sorts of projects do they do? Who are the managers and team leaders, and what are their areas of expertise or research? What is the working environment like? Do people wear jeans and shorts to work or neckties? Seeking an entry-level position, you are not going to get away with looking unkempt, wearing flip-flops and jeans, and still get that contested entry-level position.
Number two is to be enthusiastic. An employer is going to invest in you. They don’t want to hire someone to see them leave after a year or two. Organizations often take six months to a year to really bring someone up-to-speed to start working independently, and until then it’s a loss of productivity in another developer or two. If you don’t care about the work you are doing, you are less likely to want to do it well. Employers can see that when you talk to them, and are more likely to hire someone that wants to be there than someone that does not, despite slightly less experience. Not wanting to be where you are and not caring if you produce quality output is a quick way to kill motivation in a programming team. Prove to your future employer that you will be a benefit.
Now on to the technical skills. The main point to remember is that when starting out, familiarity can be much more helpful than expertise, and broad familiarity even more so than specific expertise. Especially for a new hire, you are likely not to have much exposure to the useful and important day-to-day tools of a professional development team, but your learning curve will be much easier if you expose yourself to some of what you may see. Every shop is a little different, but most have the same basic pieces in place. Get to know some etiquette and get familiar with the types of tools you will be using. My point here is that each organization has their own practices and tools, and you will need to learn how they do things. It is helpful to ask questions and contribute, but don’t expect to have their policies become your policies as a new employee. You will need to learn their way of working, and the faster you do the more productive you will be and the team that got stuck with you as a time sink will like you and respect you more and treat you as an asset sooner.
Your number one technical skill to build is using a development environment. Many Java developers use Eclipse, perhaps even most developers do. Some use it for everything, fully embracing the integrated nature of the environment, and some use external tools out of preference. Developers for other languages use other environments, such as Microsoft Visual Studio. Some use a system-default text editor and command-line. You don’t need to know about all IDEs, or even be an expert at one. What you must do is know what they are capable of and what benefits they provide. Learn how to navigate around code, outlines, and project explorers; searching all files for a function name by string is a thing of the past. Get used to using shortcut keys. Learn some of the paradigms of the popular IDEs, such as where to find menus and toolbars, whether most things are done via shortcut key or context menu, where to find help documentation, and where to tap in to the user community.
Number two on technical skills is a source code management system. Git is becoming increasingly popular in the open source world due to the workflows it can handle. Subversion is still quite popular. CVS is still used in many environments and being phased out in others. Learn the benefits of source code management and versioning. Learn how to check out, check in, properly annotate a commit message, branch and merge, deal with other developers on the same few files. Learn about patch files. Learn the pros and cons of the most popular systems, and look up why groups are migrating from one to another. Learn some of the ways these systems integrate with IDEs. Learn about the various workflows that are commonly used, such as tiered approaches or having a single central repository.
Number three on technical skills is issue tracking. Bugzilla has been around a while and most commercial and open source developers have at least heard of it. Trac is another popular option that also brings in connections to a repository, code browsing, and Wiki. Again, don’t try to learn them all, or even the names of all the ones out there. Find out what some popular ones are, look at the features they offer, look at how organizations use them, and get some practice. Some open source projects use Bugzilla for a discussion forum as well as defect investigations and enhancement requests. Others strictly use their forums for discussion and then open a ticket when they have good reason to believe it is a new issue. Learn some of the ways organizations use this kind of tool.
Now how do you go about learning all of this useful stuff? If you are at a college or university, find or start a student organization or club. I recommend a game developers organization, which brings together designers, programmers, artists, and musicians. If you are not at a college or want another path, jump on an open source project that interests you. Look on SourceForge, Google Code, github, or see if any software you use is open source and how you might be able to help. Get into a situation where you are working with other developers on a project. Practice using a source code repository and issue tracking system. Practice working with other people on a common task, collaborating and sometimes conflicting. Learn how to resolve conflict. Dive into a project being managed and learn something about project management, deadlines, bug assignment, and just teamwork in general using the tools of the trade to coordinate and communicate.
I updated the Eclipse 4 RCP Tutorial to Eclipse 4.2 M7.
M7 contains lots of small enhancements which make adapting Eclipse 4 much nicer, my personal favorite is Bug report: Application.e4xmi should be optional for which Sopot Cela provided a patch. With this patch you can convert an Eclipse plug-in into an Eclipse 4 application without creating manually any extension in the plugin.xml file.
Please give Eclipse 4 M7 a try and report bugs you find in Bugzilla.
I also thinks its about time to release my Eclipse 4 book for the Kindle. This will be an “Early Access Version” due to the fact that Eclipse 4 is still not final and that certains chapters still need some rework but should hopefully be a good reference. I plan to provide updates for this version once Eclipse 4 is released via the Kindle store.
I hope that I will be able to publish this version of the Eclipse 4 book next week. Fingers crossed.
Today's news regarding partial verdict on Oracle vs Google trial are almost all wrong.
It drives me mad to read stupid teasers like "Oracle wins" or "Google is guilty".
In short: "The judge has stated, pending judgment as a matter of law, that there is "zero finding of copyright liability" other than the 9 lines of code to which Oracle's damages report attributes no value...".
It’s been a while since Planet Eclipse got the look it has today. There is some work ongoing to refresh the look. It can be previewed on our beta site at http://planet.eclipse.org/planet-new/.
Please give us your feedback in bug 378285.
$ sudo yum groupinstall Eclipseto enjoy latest and greatest Eclipse installation, including all major projects (Eclipse itself, EMF, GEF, Mylyn, Git, WTP and others). Now it is time for the small thing - error reporting. Up until now, it was possible to do this using Mylyn:
How Do I Implement Such A Language In Xtext?
This is what the Java code generated for Mrs. H's controller looks like.
|Content Assist For Expressions|
|Call-Hierarchy Integrated in JDT|
|Content Assist For Types|
|Dead Code Analysis|
Each year Eclipse publishes 7 milestone releases before starting the endgame. Today the Eclipse and Equinox teams are proud to make Eclipse 3.8/4.2 (Juno) Milestone 7 available for download. There are a number of notable features including shiny new icons:
Content assist in in package-info files
and enhanced static analysis of case statements:
Checkout the entire new and noteworthy or download the milestone and try it out:
It was at EclipseCon NA 2012 when I run into Denis Roy and mentionned that there’s a small thing that drives me crazy all time it comes to milestone weeks.
The none release builds are not mirrowed and so downloading a build to verify my bugs is takeing for hours because they are throttled. My suggestion was to provide developers privileged access to downloads from Eclipse.org servers to solve the problem and so Denis asked me to file a bug. It was fixed in less than one week.
Yes it is the small things that matter!
It is also sophisticated enough to understand that a method or type name in Java is composed of several words e.g. 'ty + dclr' finds all 'type' + 'declarations'.
I was wondering how it is possible that Mylyn does not offer filtering incoming changes. But quick look into Mylyn user guide revealed, that it is possible, but you need to switch to 'Scheduled' mode:
And then all dates will be visible - and some scheduling categories appear - and 'Incoming' tasks. That's what I was looking for:
I do not think this is a good idea to have such an important functionality so hidden - I have filled bug 378334: Make focusing on incoming tasks easier.
The hover is also useful to temporarily 'highlight' a code block.
Once again we are releasing a new version of RAP mobile. This latest release 0.5.7 brings with it a very cool new feature that we call the “Client Canvas”. This extension of the classic SWT Canvas allows you to draw freehand on your screen with your stylus or even your finger.
Additional Features and API
The client canvas provides you with basic freehand drawing options, allowing you to sketch with your stylus or your finger. Like a regular drawing program, you can choose your color, brush size and opacity. And, you can step through the history of your drawings to undo/redo certain steps. To implement this feature we built upon the SWT Canvas object that allows us to change the pen properties via the established Canvas API. To get started with drawing you’ll just need to instantiate the
com.eclipsesource.rap.mobile.widgets.ClientCanvas instead of the regular SWT Canvas. To demonstrate the Client Canvas we have created a sample where you try out a little draw-by-numbers.
The RAP mobile Android client is catching up with iOS on browser support. We now support the SWT Browser widget, allowing you to show full websites or custom HTML snippets inside your RAP mobile application. We also support the
Support for various SWT Shell style flags
SWT offers many ways to customize the appearance of a shell via the style flags passed to the Shell constructor. These flags are also important to create SWT Dialogs. We now support the additional SWT shell styles TITLE, BORDER and *_MODAL. The following screenshots demonstrate the various style combinations.
We are constantly working towards a high level of stability and solid performance, and in this release, we squashed some bugs which deserve special mention:
- Fixed an issue where selecting elements inside a vertical ScrolledComposite was not possible
- The GraphicalContext used android APIs not available on the supported basline version android 2.1 (API level 7).
You’re probably already enjoying the browser support on our RAP mobile iOS client, and can now also take the Client Canvas for a test drive. Two other things that you might notice in this release are a new UI hint to show how to enter the developer SystemMenu and improvements to modalShell rendering and animation.
I recently sat down with Dave West and Mik Kersten in Austin, TX in order to discuss the significance of Dave joining Tasktop. I think it comes across in the video but for me personally, one of the best things about Dave joining is that we are going to have a lot of fun while we transform the world.
The term “open and transparent” rolls off your tongue. While somewhat more cumbersome to say, I tend to prefer reversing the order: “transparent and open”. I prefer this because I believe that transparent precedes open; and far more open source projects are transparent than are open.
In my experience most people seem to understand transparent. “Transparent” means that you do things in a way that others can watch. Making source code available to anybody who wants a copy is one way of being transparent. Holding project-related discussions in a mailing list with an archive that’s accessible to anybody with an Internet connection is another way of being transparent. There are many more examples, like making your issue tracker available, hosting public discussion forums, and more.
Transparent does not mean open.
Open is a little harder. “Open” means that you do things in a way that others can participate. It means that you provide a level playing field: everybody participates using the same set of rules. Being transparent is easy; being open is hard.
Being open is more than just accepting code patches, and permitting outsiders to create bug reports.
Being open and having a true level playing field is hard because it requires that you give up absolute control. In an open project, control is shared. When the playing field is truly level–with the same set of rules applies to everybody–it’s possible that somebody can arrive at your project and change the way that you do things. This is not to say that anybody can show up and start making arbitrary changes to the code. Rather, it means that there exists a set of rules and conditions by which anybody can earn the right to participate as an equal member.
The rules need not be explicit or quantitative. Though, it does help if they are.
Take a look at the developers on your project. Do they all work for the same employer? When was the last time you added a new developer to the project? Do you accept contributions from “outside” contributors? How hard do you work to convert those “outside” contributors into full participants and decision makers on your project?
Operating in an open manner, actively courting participation to turn outsiders into insiders increases the diversity in the project and in so doing increases its strength and durability.
Transparent is good. Transparent and open is better.
For the last 3 years we have done a survey of the Eclipse community to better understand what developers are doing with Eclipse and open source. The survey results have provided some interesting insights into the trends of the general software development community.
We have now launched the 2012 edition of the Eclipse Community Survey. I’d like to invite everyone in the Eclipse community to complete the survey. The survey should take 5-10 minutes to complete so it shouldn’t be too time consuming. As an extra incentive, participants can enter a draw to win a pass to EclipseCon Europe 2012 or EclipseCon NA 2013 and some Eclipse SWAG. In June, we will publish a complete report of the survey results.
Thank you in advanced to everyone that does fill out the survey. The deadline to complete the survey is May 15, 2012.
This year, the Eclipse Day in Delft will focus on tools and techniques to support the software development process, including software maintenance.
Call for Contribution
Call for papers is now open!If you would like to present your exciting tools or techniques to support software development or maintenance, or share an experience report at the Eclipse Day Delft 2012 please send your proposal by June 27, 2012 to email@example.com. For more details on the proposal format and requirements see the Call for papers.
Two weeks shy of ten years ago, I joined Red Hat as an intern on the Red Hat Database team. I was incredibly lucky to have gotten that internship and then to have been hired on full time 2 years later. I’ve had a great time working at Red Hat but have made the very difficult decision to leave. My last day is tomorrow, Monday April 30th.
Red Hat has provided me with many things: innumerable learning opportunities, career growth, exposure to open source communities, public speaking opportunities at conferences, and more. Most importantly, though, I’ve been given the chance to work with a lot of really amazing people both inside Red Hat and in a variety of vibrant Free Software and Open Source communities.
The Eclipse community has been my home for a few years now. It’s full of some of the most talented and passionate software developers I’ve ever met. I plan to remain involved in the Eclipse world and am looking forward to getting Linux Tools 1.0 released as a part of Juno and what comes after that!
I’ve excited for my new job but have a few weeks of down time in between where I hope to largely be AFK. I’ll write a blog entry here when I start my new job. I’ll still be around the open source world and if you’d like to contact me I’m reachable here on my blog or via various social networks. I wish everyone continued success both personally and professionally. Thanks for everything and I’ll see you around.
I proudly announce the official OpenChrom release version 0.6.0 “Synge”.
Note, that Java 7 is required. The documentation is in progress and will be extended. Several improvements are available now, e.g.:
- Varian *.SMS converter (experimental)
- Basic mzXML support for the 3.1 and 3.2 specifications
- Peak identification batch support for peaks modelled by PARAFAC/MCR algorithms
- Chromatogram database plug-in
- PDF and ZIP chromatogram export capabilities
- Export chromatogram peaks to *.msp format, which can be loaded by the NIST-DB
- Better process feedback
- Completely reworked marketplace
- Full update functionality
Go there, get it:
i'm pleased to announce the 1.0.2 release of perlipse.
here's what's new and noteworthy:
- java 1.6 is now required
- updated plugin versions to use a 'qualifier'
- added 'branding' plugin
- no longer uses deprecated dltk methods*
- parser bug fixes and AST work
- ppi4j parser is now the default parser on new installations
- issue 26 has been fixed and a new preference introduced to set the color of back tick strings
the thing i am most excited about in this release though are the new icons provided by new project contributor, james lauer!
head on over to the project page for more details.
* the one exception to this is code folding which is going to require an entire re-write.
|Site||CI system||Build system||VCS||Trigger||Notification||Pricing||Deployment||Comment|
|Travis CI||Travis||Maven, Ant, and others||git (github only)||github: Travis hook||free for OS||no||still alpha|
|CloudBees, FOSS free||Jenkins||Maven||git, SVN, and others||github: Jenkins hook||?||free for OS||?|
|FaZend||Hudson||Maven, Ant, and others||SVN||?||free||?||still beta|
|CodeBetter||TeamCity||Maven||git, SVN, and others||github: TeamCity hook||email, Jabber, and others||free for OS||?|
|Shining Panda||Jenkins||Maven||git, SVN, and others||github: Jenkins hook||€0.36 / hour||?||Focused on Python|
|Jenkins Hosting (Bubbleware Technology)||Jenkins||?||git, SVN||?||?||free for OS (+ Amazon EC2 fees)||?|
|continuous.io/||?||?||?||?||?||free for OS (+ Amazon EC2 fees)||?|
- Trigger: This means how the build is triggered. This is of course not a feature of the CI system itself, but of the source code repository. Github or Bitbucket provide some hooks, unfortunately, EclipseLabs (GoogleCode) doesn't, or does it?
- Notification: This means how the system does notify the user of the build result. After a successful build, one probably want to somehow deploy the created artifacts.
- Deployment: Actually, I'm looking for a solution of copying the artifacts, which actually are a P2 repository, to some download or update site. Of course, this could be achieved by Maven plugins or Ant tasks, however, the crucial point is how to pass some credentials (user name, pass word) to the build system. Especially if you are building an open source project, you do not want to write this information into the maven script. Seems as if this is a common problem. If this problem were solved by Travis, it would be the best solution, at least for github projects.
Actually, it is very hard to determine the features of the different solutions. Many projects seem to be in a very early stage, and some projects announced are already gone (e.g., Mike CI). Most projects are cloud based, some use Amazon EC2 and users need their own Amazon EC2 account. For open source projects, it is often required to fill out some request form, and I don't know whether all projects are accepted.
Leave me a comment if you have any experience with a solution listed above, or if you know of other hosted CI systems.