Twitter github

Posts Tagged with “eclipse”

The Company-Customer Pact

I’m not a fan of anonymous feedback or anonymous communication, especially if you’re trying to build a community around something. I recently came across the Company-Customer Pact which I highly recommend people read as it embodies a lot of things I believe in.

Challenge

We, customers and companies alike, need to trust the people with whom we do business. Customers expect honest, straightforward interactions where their voices are heard. Companies work to inspire brand loyalty and deliver satisfaction while trying to understand their customers better. It is evident that we all have a crucial stake–and responsibility–in transforming the adversarial tone that too often dominates the customer experience.

A Call for Shared Responsibility

Along with open, authentic communication comes the mutual responsibility to make it work. As each of us is both a customer and an employee, we share in the rewards and challenges of candor. By adopting these five practical measures, we can together realize a fundamental shift in our business relationships:

What do people think?

Any lessons we can take away that would benefit the Eclipse community?

I’m growing a ‘stache

To the dismay of my stylist, I’m growing a ‘stache for Movember.

big stache

Apache may have their 10th anniversary, but Eclipse committers are growing ‘staches for prostate cancer awareness this month.

Since I’ve been involved with open source for quite awhile, I’m used to doing things in a transparent fashion. I decided to create a poll for the type of moustache I should grow, seeking community input.

moustache

I’m currently favoring the “major” … in the end, I hope I an rock a moustache like Orlando Bloom or Johnny Depp. So please, vote for my ‘stache and I’ll announce the results this Friday. While you’re voting, please take time to donate if you have the resources.

Eclipse and Content Type Definitions

I came across a bug in PDE recently regarding content types.

For example, let’s pretend you had a xml file like this:

<?xml version="1.0" encoding="UTF-8"?>
<scr:component xmlns:scr="http://www.osgi.org/xmlns/scr/v1.1.0" 
    name="Command Provider for Dictionary Service">
   <implementation class="org.eclipse.example.ds.ServiceComponent"/>
   <service>
      <provide interface="org.eclipse.osgi.framework.console.CommandProvider"/>
   </service>
   <reference 
      bind="setDictionary" 
      cardinality="1..1" 
      interface="org.eclipse.example.ds.DictionaryService" 
      name="Dictionary" 
      policy="static" 
      unbind="unsetDictionary"/>
</scr:component>

And this content type extension definition:

<extension
         point="org.eclipse.core.contenttype.contentTypes">
      <content-type
            base-type="org.eclipse.core.runtime.xml"
            file-extensions="xml"
            id="org.eclipse.pde.ds.core.content-type"
            name="%content-type.name"
            priority="high">
         <describer
               class="org.eclipse.core.runtime.content.XMLRootElementContentDescriber2">
            <parameter
                  name="element"
                  value="component">
            </parameter>
         </describer>
      </content-type>
</extension>

Looks ok, right? The content type should be associated with files that start with the component tag. Cool! Well, the problem is since Eclipse is open for contribution, someone else can come along and define a “component” format and than you have the problem of your editor associations being messed up. Many bad things can happen.

<?xml version="1.0" encoding="UTF-8"?>
<component name="stuff">
    <...>
</component>

The fix is to have my content type definition scoped by namespace. This is trivial since XMLRootElementContentDescriber2 supports namespaces.

<describer
     class="org.eclipse.core.runtime.content.XMLRootElementContentDescriber2">
     <parameter
             name="element"
             value="{http://www.osgi.org/xmlns/scr/v1.1.0}component">
     </parameter>
 </describer>

You learn something new everyday.

Eclipse Summit Europe 2009

I’m presenting at Eclipse Summit Europe 2009 which happens in about a week from today.

I’ll be speaking about OSGi Versioning and Testing with Jeff McAffer and Paul VanderLei. Please consider coming to the talk, it should be fun and will involve discussion of painting fences with neighbors.

Fences

Here’s the abstract:

The old saying goes, good fences make for good neighbors. Modular systems are all about the fences, otherwise known as contracts. OSGi-based systems are simply compositions of modules and contracts. To express contracts in OSGi, we use version numbers. From our experience in the Eclipse community, we have found that managing API and these contracts a difficult process.

In the first part of this talk, we’ll discuss the problem of version numbering and managing change. We’ll bring forward real world examples that demonstrate the complexities in managing change, including examples from the Eclipse community where change has caused havoc. There will be a demonstration of some the tools we developed at Eclipse to help manage change in your OSGi-based applications.

In the second part of this talk we draw on experiences and examples from the OSGi and Equinox book to identify key elements of modularity and point out best practices for designing and building modular systems using OSGi. Along the way we highlight pitfalls and anti-patterns and talk about ease of testing as barometer for modularity.

On a side note, over 30 people have signed up for the Eclipse Summit Europe 5K run every morning!

Eclipse Summit Europe 5K

Please don’t forget to sign up if you want to run and burn off some Kirsch.

Browsers are hungry for memory too

I think over the past few years, my internet browsing experience has steadily decreased.

From Firefox leaking memory like a sieve to Safari officially eating more memory than Eclipse on a consistent basis.

Safari vs. Eclipse

Memory, it’s what’s for dinner.

Eclipse, Linux and Embedded

I read an interesting bit of commentary lately on Eclipse’s impact on the Embedded industry…

What a difference a decade makes. In 1999, every embedded systems tool provider who had an RTOS and a set of tools supported them with a proprietary integrated development environment (IDE), tying everything into a neat tightly connected tool chain.

Now, one of the last holdouts – Texas Instruments – has abandoned its proprietary IDE in favor of one based on open source Eclipse. The transition is complete, with virtually every major embedded software vendor supporting their own implementation of Eclipse, including Wind River, Green Hills, QNX, Lynux Works, Rapid Logic and Mentor Graphics, among others…

This is good news for Eclipse given that I view the embedded community tough as nails. These are folks that have an affinity for TCL and autotools. Ok, maybe that’s a generalization, but I still have nightmares dealing with autoconf and obscure m4 messages that were impossible to debug. In the commentary, the author asks, “What are some of the other things we can look forward to?” That’s a good question and I’m not really sure, but I have some things on my mind.

For embedded developers that live in the C/C++ world, the plan for Eclipse Helios (3.6) includes flexible resources

The Resource architecture that Eclipse uses has been criticized for being overly Java-centric and constraining for some use cases. The e4 incubator explored this problem and developed some concrete improvements to the resource model to address these problems. We will review and polish those changes and back-port them to Helios stream where appropriate.

Flexible resources should enable a new set of workflows for embedded developers that are used to other environments like Visual Studio. Here’s a webinar if you want to know more.

Another thing that may be interesting to embedded developers is the Linux Tools project at Eclipse which aims build on top of CDT and integrate popular native development tools such as the GNU Autotools, Valgrind, OProfile, RPM and Systemtap. If you browse the Linux Tools new and noteworthy page, you can easily see the great progress their making.

Can anyone think of other things that embedded developers can look forward to?

Eclipsepedia and FCKeditor

Eclipsepedia got a subtle upgrade yesterday with the FCKeditor extension.

fckeditor

It should be easier to edit wiki pages for people who don’t like to deal with the wiki syntax directly.

If you love wiki sytnax, simply select the ‘Wikitext’ button:

wikitext

Thank you Eclipse webmasters!

Lowering Open Source Contribution Barriers

At this time of year within the Eclipse community, a lot of reflection goes on as we just shipped a major release. Personally, I have been reflecting on a statement from an article:

…the strength of Mozilla, for example, is that it has figured out how to enable 40 percent of its development to be done by outside contributors. The downside is that these contributors are techies, but the upside is that they’re techies who add language packs, accessibility features, and other “niche” areas that Mozilla might otherwise struggle to deliver.

This suggests a start: enable your open-source project to accept meaningful outside contributions that make the project reflective of a wider development community.

But the real goldmine is broadening the definition of “developer” to include lay users of your software. The day that I, as a nontechnical software user, can meaningfully participate in an open-source project is the day that open source will truly have won.

What has Eclipse done to broaden the definition of a developer?

As Bjorn Freemen-Benson wrote, Eclipse enabled people to contribute translations via the Babel project. The Babel project is setup to accept translation contributions in 34 languages for about 40+ Eclipse projects. As a matter of fact, Babel had a recent release where there were some positive statistics on how translations are coming along.

What else? How about improving our documentation process?

I’m fond of what the Mylyn project does with its documentation. The Mylyn User Guide is crowdsourced via the Eclipsepedia wiki. This enables the Mylyn team to leverage their user community to help contribute documentation and have it appear in the official help documentation. As far as I know, the Mylyn project is currently the only Eclipse project doing this.

How about interacting with talented artists within our user community? I griped about this awhile ago. I had an idea about creating a GraphicsZilla where people can submit requests for graphics and having things tracked… just like we do with bugs!

Also, how about us making it easier for users to file bugs? My ideal would be to see some type of feedback agent included in Eclipse to facilitate users filing bugs. I think we have come a long way with Mylyn integration in Ecilpse… there’s some just loose ends that need to be tied up to make the experience even easier for users.

Other than that… that’s all that comes out of my head at the moment.

In my opinion, we have a great community… we just need to figure out how to leverage it more.

crowdsource

What do you think Eclipse can do to broaden the definition of a developer?

As a Eclipse committer, it’s hard for me to put myself in the perspective of a user… but I try 😉

Git Mirrors @ Eclipse?

Do you love Git?

git-trunk

Do you want to see Git at Eclipse (like other people)? Do you already mirror some of the Eclipse code base with Git?

If so, I think a good first step would be to host a Git mirror for the Eclipse code base, similar to what Apache does. In my opinion, this would at least enable people who already maintain forks of the Eclipse codebase make it easier to contribute back.

If you like this idea or have some experience with git mirroring, feel free to comment on this bug.

Frosty Beverages in Berlin

Are you in Berlin tomorrow?

Do you want to have some frosty beverages with the Eclipse Board of Directors and chat about Eclipse-related things?

Frosty Beverage

If so, please join us at the Bavarium at 7pm.

Personally, I’m excited to practice my German, “Eine Berliner Weiße mit Schuss, bitte!”