text:
tag:blogger.com,1999:blog-250232802019-04-21T00:41:55.673-07:00Releng of the NerdsOpen Source Release EngineeringKim Moirhttp://firstname.lastname@example.com:blogger.com,1999:blog-25023280.post-55776532582825885642017-05-17T14:12:00.000-07:002017-05-17T14:12:22.831-07:00New blog locationI moved my blog to WordPress.

New location is here https://kimmoir.blog/Kim Moirhttp://firstname.lastname@example.com:blogger.com,1999:blog-25023280.post-51550975200297096802016-07-29T12:06:00.003-07:002016-07-29T12:06:32.657-07:00Eclipse Committer EmeritusI received this very kind email in my inbox this morning.

"David Williams has expired your commit rights to the
eclipse.platform.releng project. The reason for this change is:

We have all known this day would come, but it does not make it any easier.
It has taken me four years to accept that Kim is no longer helping us with
Eclipse. That is how large her impact was, both on myself and Eclipse as a
whole. And that is just the beginning of why I am designating her as
"Committer Emeritus". Without her, I humbly suggest that Eclipse would not
have gone very far. Git shows her active from 2003 to 2012 -- longer than
most! She is (still!) user number one on the build machine. (In Unix terms,
that is UID 500). The original admin, when "Eclipse" was just the Eclipse
Project.

She was not only dedicated to her job as a release engineer she was
passionate about doing all she could to make other committer's jobs easier
so they could focus on their code and specialties. She did (and still does)
know that release engineering is a field of its own; a specialized
profession (not something to "tack on" at the end) that just anyone can do)
 and good, committed release engineers are critical to the success of any
project.

For anyone reading this that did not know Kim, it is not too late: you can
follow her blog at

http://relengofthenerds.<wbr></wbr>blogspot.com/

You will see that she is still passionate about release engineering and
influential in her field.

And, besides all that, she was (I assume still is :) a well-rounded, nice
person, that was easy to work with! (Well, except she likes running for
exercise. :)

Thanks, Kim, for all that you gave to Eclipse and my personal thanks for
all that you taught me over the years (and I mean before I even tried to
fill your shoes in the Platform).

We all appreciate your enormous contribution to the success of Eclipse and
happy to see your successes continuing.

To honor your contributions to the project, David Williams has nominated
you for Committer Emeritus status."

Thank you David! I really appreciate your kind words. I learned so much working with everyone in the Eclipse community. I had the intention to contribute to Eclipse when I left IBM but really felt that I have given all I had to give. Few people have the chance to contribute to two fantastic open source communities during their career. I'm lucky to have that opportunity.

My IBM friends made this neat Eclipse poster when I left. The Mozilla dino displays my IRC handle.

Kim Moirhttp://email@example.com:blogger.com,1999:blog-25023280.post-75757466873778447182013-03-26T06:04:00.000-07:002013-03-26T14:58:50.986-07:00Thoughts on being a second generation geekWhen I was in Toronto for our last work week, I mentioned to one of my colleagues that I was a second generation geek. He replied something to the effect of "There are families that have been fishing lobster for eight generations but not many second generation geeks."

I'm a second generation geek thanks to the influence of my Dad. My sister also works in the software industry, as a technical writer. My parents both had a tremendous influence on us. If it wasn't for their support and encouragement, I doubt that we would be where we are today.

My Dad's first technology job was working at Burroughs in Vancouver, BC as a field service technician and manager. He would travel to customer sites to fix their computers, usually at banks, insurance companies or government. Back then computers were very large, not very common, and they had a longer lifecycle than we see today. He had a briefcase full of tools to fix them, given that most problems were mechanical or electrical in nature, as opposed to software.

About a decade later, our family moved across the country and he started working as a technical services manager at a small software and services firm in Halifax, NS. This was the dawn of the PC era, and he brought home a succession of computers for him to learn about, as well as the rest of our family. Dad would bring home stacks of computer magazines and manuals to read at nights on weekends, which I started to read as well. We had many spirited discussions about technology, and what the future would hold.

In addition to having a wealth of technical knowledge, my Dad is also an accomplished woodworker and builds beautiful furniture. He bought my sister and I hammers so we could work along with him in the workshop. There was also an abundance of Lego, his old Meccano kit, and stacks of science fiction books. Christmas meant the inevitable gifts of conference swag in stockings, or a Linux book under the tree.

Over the years, I have returned the favour and given my parents a lot of the swag I've received at work. I'm sure they have the finest collection of Eclipse wear in Nova Scotia. But this year begins a new tradition.

My Dad loves Firefox too

I've noticed that many of my (female) friends who work in software had a parent who worked in the industry and thus were a source of influence for their choice in career. I learned from both my parents was to work very hard. From my Dad, I learned that
1) Change in this industry is constant and it makes things interesting.
2) Continuous learning is essential. Take courses, read voraciously, break things and fix them.
3) STEM careers are for women.

Thanks Dad!

This past weekend, I asked him if there were ever any women at tech conferences when he attended them in the 1980s or 90s. He replied that there was usually one or two, but that was all.

He then proceeded to tell me a story about a technical sales manager who he worked with for many years named Eli. She had worked in an administrative capacity at Digital Equipment Corporation (DEC), but wanted to become a salesperson. She was told that there was absolutely no way that she could be become a salesperson and represent DEC to customers because she was a woman.

In those days, computers were sold from OEMs (original equipment manufacturers like DEC) or VARs (valued added resellers). The company where my Dad worked at was a VAR and had agreements with various OEMs, including DEC. They would package hardware and software from several companies, along with installation and support services into sales proposals to meet customer requirements. The funny thing was that VARs and OEMs would often compete for the same customers since they both sold the same branded hardware. The VARs weren't limited to selling to a single vendor, but the OEMs had more flexibility in pricing in margins since they were the manufacturer. Sales margins on hardware were quite high compared to what they are today, and thus a job as a salesperson could be quite financially lucrative if you were good.

Eli left DEC to work as a sales manager at the same office where my Dad worked. She proceeded to outsell all the salesmen at her her previous employer who had refused to let her be a salesperson because of her gender, and won many sales awards. So awesome!

I was always was a bit intimidated by Eli. She was tough as nails, with a wicked sense of humour. I can imagine that it wasn't always an easy path she had to walk, given that being a professional woman and working in technology was not common at the time, especially is socially conservative Nova Scotia. But she did it, and proved that she could rise above her detractors.

A second thanks to women who have blazed trails in the past :-) Who inspired you to choose your career in STEM?

Kim Moirhttp://firstname.lastname@example.com:blogger.com,1999:blog-25023280.post-90618748435514177952012-08-31T13:12:00.000-07:002012-08-31T13:12:23.151-07:00New platform tests: OS X Mountain LionLate Monday night, we moved a new testing platform into production. We have 80+ shiny new Mountain Lion slaves running tests for desktop builds, with several reserved for staging tests. There are a few issues with failing tests that are being tracked in bug 786084.

Image ©ekai, http://www.flickr.com/photos/ekai/457004988/ licensed under Creative Commons by-nc-sa 2.0

This was one of the larger projects I've worked on since I started at Mozilla a few months ago. Many of the existing test and builds slaves that we run are configured with an old installation of Puppet (0.24.8) that we call "pre-historic puppet". We have a newer installation of Puppet running 2.7.19 nicknamed PuppetAgain that serves as the Puppet Master for these new Mountain Lion slaves. The PuppetAgain installation used to just support CentOS slaves, so we added modules to support the Mac slaves and accommodate all the quirky Apple specific configuration needs.

Given my experience as an Eclipse committer, I installed the Geppetto project as my Puppet manifest editor and it's a great tool. Thanks to the folks at Cloudsmith for developing it, it has been very useful.

In addition to becoming familiar with Puppet, I also had the opportunity to learn about the releng buildbot configs, adding new buildbot masters, updating graphing databases to store Talos results, running staging tests and all the steps to add a new platform. Since the process wasn't documented, I wrote up some notes to help others if they need to do the same.

Thanks to everyone on the release engineering and release engineering operations teams for all their help, especially answering my many questions and reviewing patches. Its great to see something that you worked on in production, and finally generating green builds.Kim Moirhttp://email@example.com:blogger.com,1999:blog-25023280.post-19773601388747149782012-06-24T14:15:00.000-07:002012-06-24T14:15:29.302-07:00Learning to speak like a native MozillianAside from gaining experience with the technical requirements of a new job, there's also the challenge of learning the terms within the community as well as cultural norms. There's time spent finding the right code repositories, documentation and test servers. Who's the right person to cc on a bug or ping in IRC? When learning a foreign language, they say that if you're still translating in your head before you speak, you're still learning. Here are some terms and conventions I learned during my first weeks at Mozilla.

Release some code to a production branch or stream on the canonical repo
Mozilla: to land
Eclipse: to release or commit

People
Mozilla: Lots of people named John, Chris and Mike, many Canadians
Eclipse: Lots of people named John, Chris and Mike, Canadians represent too

Image ©meddygarnet, http://www.flickr.com/photos/blakespot/5240888169/sizes/z/in/photostream/ licensed under Creative Commons by-nc-sa 2.0

Where bugs rain down from
Mozilla: https://bugs.mozilla.org
Eclipse: https://bugs.eclipse.org

The source of all truth, which may contradict itself
Mozilla: http://wiki.mozilla.org
Eclipse: http://wiki.eclipse.org

The version control system(s) to alternately love and shake your fist at
Mozilla: Hg with some Git, Subversion, CVS and Bazaar
Eclipse: Git with a side order of CVS and Subversion. (Side orders will be deprecated soon)

Image ©clsung, http://www.flickr.com/photos/clsung/310886130/sizes/z/in/photostream/ licensed under Creative Commons by-nc-sa 2.0

Colloquial expression for the associated open source foundation
Mozilla: MoFo
Eclipse: the foundation

Time for liquid refreshment
Mozilla: MFBT
Eclipse: Beer o'clock

Image ©Cambridge Brewing Company , http://www.flickr.com/photos/cambridgebrewingcompany/5619040409/sizes/z/in/photostream/ licensed under Creative Commons by-nc-sa 2.0

Communication channels in order of importance
Mozilla: IRC, mailing lists, Bugzilla
Eclipse: Bugzilla, mailing lists, Twitter, IRC

Image ©blakespot, http://www.flickr.com/photos/blakespot/5240888169/sizes/z/in/photostream/ licensed under Creative Commons by-nc-sa 2.0

Code review
Mozilla: review flag in Bugzilla for all patches
Eclipse: review flag in Bugzilla at the end of the release cycle, others use Gerrit all the time

Incredibly smart and friendly people with a passion for delivering fantastic open source software
 +1 Mozilla and Eclipse

What have I missed?

Disclaimer: This is just based on my own personal experience. YMMV.Kim Moirhttp://firstname.lastname@example.com:blogger.com,1999:blog-25023280.post-6147623245687788932012-06-24T11:57:00.000-07:002012-06-24T11:57:20.225-07:00Challenges in Release EngineeringI've been at Mozilla since the end of April. The learning curve is steep but I'm having fun climbing. My coworkers are very friendly and helpful while answering my barrage of questions with respect to how things work. One of the things I've noticed is that there are many common challenges in release engineering, no matter what you're building. Here's my list so far:

1. Signing builds is like a falafel sandwich. (Always includes some pita).

Image ©chotda, http://www.flickr.com/photos/santos/3531853459/sizes/z/in/photostream/ licensed under Creative Commons by-nc-sa 2.0

2. Scaling your build to manage infrastructure utilization, tooling to manage that infrastructure and optimizing build parallelization is extremely challenging. Developers will consume all available build infrastructure and then ask for more. Scaling build infrastructure to accommodate future growth is an ongoing process.

3. Proliferating numbers of platforms on which to build, test and run performance metrics add complexity.

 Image ©misterbisson, http://www.flickr.com/photos/maisonbisson/109211670/sizes/o/in/photostream/ licensed under Creative Commons by-nc-sa 2.0

4. Update game adventures. When you have an open platform that included the installation of third-party components, it's inevitable that you will encounter unexpected update cases in the wild that weren't reflected in test cases.

5. Frequent releases generate faster user feedback on new features. However, additional releases are expensive for the release engineering, quality assurance and release management teams. Each additional release eats time, both people and machine. Making the community aware that builds are not free is an ongoing communication exercise.

Image ©aarongeller, http://www.flickr.com/photos/aarongeller/360135019/ licensed under Creative Commons by-nc-sa 2.0

6. You can have great documentation and process but the accumulated technical and tribal knowledge required to resolve a complex and broken build quickly is not earned by anything other than experience.

 Image ©Ian Muttoo, http://www.flickr.com/photos/imuttoo/2631466945/sizes/z/in/photostream/ licensed under Creative Commons by-nc-sa 2.0

7. If you can compile your code, this doesn't mean there won't be issues with packaging, signing and testing it. Making a build available in a format for millions of users to consume > code that compiles. Education is needed to make people aware of this distinction.

What release engineering challenges do you face?Kim Moirhttp://email@example.com:blogger.com,1999:blog-25023280.post-63910440674878703782012-03-08T06:39:00.000-08:002012-03-08T06:39:51.938-08:00Moving to MozillaEclipse family: March 23 will be my last day at IBM. I'm happy to announce that I'll be joining the Mozilla Release Engineering team in April.

Image ©flod, http://www.flickr.com/photos/flod/2221300134/sizes/l/in/photostream/ licensed under Creative Commons by-nc-sa 2.0

We all wear many hats during our lives. I've always been fiercely proud of the privilege of calling myself an Eclipse committer. We've accomplished amazing things together. I look forward to seeing the continued growth and success of the Eclipse community.

At Mozilla, I'll have the opportunity to work with a completely new software stack, and learn many new skills while working with very talented people. Best of all, my job will involve contributing to an open source community. This is what I love to do. The Mozilla goals of making the web better, and teaching a new generation to make content, instead of just consuming it, really resonate with me. Running builds on 1200+ machines raises some interesting scalability issues which I'm eager to learn more about. It will be challenging work, and I'm honoured to have the opportunity to work at Mozilla. I'll be working from my home in Ottawa.

Where there are new challenges ahead for me, at the same time it has been a difficult decision to let my contribution to Eclipse wane. I'd like to continue contribute to Eclipse in some way but on a part-time or occasional basis.

My IBM colleagues, my fellow committers and the Eclipse foundation staff: you are all extraordinary. It has been a privilege to work with you and learn so much. To those in the larger Eclipse community, you inspire me. To the people on the Eclipse SDK and Equinox teams, I have never had the opportunity to work with such a wonderful group of people. Not only are you creative and technically brilliant, but you are all so dedicated to doing the right thing and getting things done. You're all genuinely nice people, without ego, who are eager to share your knowledge with others. It's not often that software project ships on time every year for ten years and continues to delight its user community. It is a testament to the team behind it that this continues to be the case.

In the process of working on Eclipse, I've met some fantastic people, many who have become great friends. I'll miss the seeing your faces every day and discussing the finer points of Git migration strategies, but I'll still be on IRC, Twitter, Linkedln, G+ etc. If you live in the Ottawa area, I'm always up for lunch :-)

It has been a great run. Thank you all

Note #1: I'll continue to write on this blog. The name still applies :-)
Note #2: I was going to call this post "Firefox-y Lady". Then I read the lyrics to the Hendrix song "Foxy Lady" and decided maybe not.Kim Moirhttp://email@example.com:blogger.com,1999:blog-25023280.post-20016906101825012202012-01-16T11:46:00.000-08:002012-01-17T07:54:51.076-08:002011 by the numbers2011 was an exciting year in the Eclipse community. From my corner of the Eclipse universe, he's what it looked like:

One book chapter, many thanks

I contributed a chapter on Eclipse to the Architecture of Open Source Applications in 2010 and the book was published in May 2011. Thanks to Amy Brown and Greg Wilson, for their long hours editing and providing feedback to the authors of this book. It's a great read! When Greg first approached me about writing this chapter, my immediate thought was "How hard could it be? I live and breathe Eclipse all day". It was much more difficult that I imagined but in the process I learned a tremendous amount and am a better committer for the experience. Many thanks to DJ Houghton and John Arthorne for reviewing my drafts and providing valuable feedback. A special thanks to Jeff McAffer who I interviewed about the decision to switch to OSGi in 3.0 and Steve Northover for his suggestions to make the SWT section into something more pixel perfect. Merci Olivier Thomann for answering my many compiler questions, and Boris Bokowski and Paul Webster for their thorough discussions with me regarding the modelled workbench and dependency injection in 4.x. Also, thanks to Mike Wilson to allow me the flexibility in my job to spend some time at work working on this chapter. I'm excited to see that Amy and Greg are now editing a second volume of this book.

Six milestones, many release candidates, two service releases, and one coordinated release, four streams, thousands of builds, millions of tests
No rest for the committers.

143 bug fixes
I closed about 143 bugs in the releng bucket in the past year. That doesn't seem like much really. I'd have liked to solve more. The largest issues implemented from a releng perspective were shared licenses, code coverage, and the largest work item, the Git migration.

42 Git repos
The Equinox and Eclipse projects migrated all their repos to Git. We now have about 42 Git repos. This involved a tremendous amount of work on the part of the Eclipse team as a whole. There were many whiteboard drawings and detailed discussions about the migration process with John, Paul and a Mr. Gheorghe. There was no Ringo. Thank you Paul for all the huge amount of testing, script writing, and migration of all the ui and e4 repos. Thanks John for your work many sage suggestions on our Git migration, as well as your suggestion to implement the git flow method to simplify our development and build processes. Thanks Andrew Niefer for migrating many of the Equinox and PDE repos, Bogdan Gheorghe for your work with SWT, and Oliver Thomann for testing JDT Core repos. Thanks Tom Watson for your Git advice, having already climbed the Git learning curve while working on the OSGi Alliance repositories. To Dani Megert and Markus Keller, your always fine attention to detail and pointing out areas that could be improved is appreciated. Paul is giving a talk about our migration at EclipseCon 2012 called Let's Git this Party Started. I'm sure it will be insightful and entertaining.

One EclipseCon, two talks, one castle, many great people
I was privileged to attend EclipseCon Europe in Ludwidsberg this past November and present two talks. I thoroughly enjoyed preparing these talks, and even more presenting them. On the Wednesday morning, I talked about our Git Migration, and that evening I gave a talk with John Kellerman about history of Eclipse over the past 10 years. After the second talk, a few people came up to me and said that the talk was so good that it should have been a keynote. That was very fantastic to hear because we really put a huge amount of effort into that presentation. I also had a lot of fun talking to people at our booth where we had posted many pictures of the Eclipse family from over the years. The Saturday after the conference Simon Kaegi, Eric Moffatt and I visited Heidelberg castle. Canada scores very low on the castle index so this was a treat.

You can't buy Eclipse magazines or giant pretzels at train stations in Canada either. I was impressed.

19 blog posts
I didn't have much time to write blogs posts this year. The most popular one I wrote this year was about smashing open source stereotypes.

I'm never sure how popular a blog post will when I write them. It's always a surprise. The comparison of Mozilla and Eclipse build infrastructure I wrote last year still holds the record for most popular (it ended up on reddit).

One marathon, many kilometers of training
How is running related to release engineering? Running keeps me sane when release engineering gets crazy :-) Preparing for the Ottawa marathon in May means that you have to start training at the end of January. Running through snow, ice, wind and rain teaches you there isn't really anything you can't do when you are willing put in a lot of hard work to reach your goal. And when you reach that goal, there's a lot of joy, because you know that you have conquered all the obstacles in your path and emerged victorious.

My sneakers after a 19K training run through deep slush

Open source is really a huge team effort and I had a lot of fun in the Eclipse community in 2011.

Who knows what 2012 will bring?Kim Moirhttp://email@example.com:blogger.com,1999:blog-25023280.post-43391101971212296602011-11-22T18:34:00.000-08:002011-11-22T18:38:55.605-08:00We're the face of open sourceI had some interesting discussions on Twitter this afternoon.

Wayne replied:

Miles said:

One of the great things about the Eclipse community: that we cooperate on open source projects yet compete on commercial products. This slide from the Eclipse 10 years talk that John Kellerman and I recently gave shows the diversity of the CDT project by company.

Here's another slide where we talked about the fact that there weren't originally enough non-IBM committers on the Eclipse project. I called this "Too much blue in the Eclipse rainbow".

Image ©darrentunnicliff, http://www.flickr.com/photos/darrentunnicliff/4510834607/ licensed under Creative Commons by-nc-sa 2.0

I'd like see a more diverse community at Eclipse and in open source in general. To spread the word that it's a rewarding career and we have a wonderful community. Also, I'd like to find more people to fix bugs :-)

Occupy Open Source: We are the 1%

I don't know if the percentage of women at Eclipse is really 1% but it's pretty low.*

Ian later tweeted

My response was that it would be interesting to focus on the person, where they had come from and what they work and work the technology into the discussion. Show a picture of the person, what their educational background is, how they got involved in open source, and what they work on. I think computer science and open source have an image problem. People think that we software isn't a social endeavour. And yet it is. Hello GitHub. That the work we do doesn't change the world and make people's lives better. No again.

One of the ways to combat stereotypes tell stories from the perspective of the person. How they came to work in open source. The interesting projects they work on. Talks they presented at conferences. What they do in their spare time outside work. Curtis writes code for PDE but he also likes to kayak. Susan works on Orion but also runs an organic farm. Andrew writes Linux tools but he also has interesting travel adventures. Eric works on the next generation Eclipse UI and wins pool tournaments. Tom works on that too, and he likes to ski and hike near his home in Innsbruck. Ian lives in Victoria, works on p2 and plays hockey. Introduce the person, then move on to talk about the technology they work on :-)

Yesterday, Syzmon asked me if me if could use our Eclipse 10 Years talk at a demo camp in Poland. I thought that was fantastic. Our talk delivered in another country, in a different language. Go Creative Commons.

Putting these too ideas together, I thought it would be interesting to have a common slide deck we as a community could use at schools or universities called "We're the face of open source". I think it's important to showcase the different paths people take to get to their careers. And kids need to to see something of themselves reflected in people who work in the industry. It doesn't matter if you're a man or woman, your ethnicity, where you live, if you're gay or straight, have five kids or three dogs. The important thing is that you have a story that you want to share to inspire a new generation to consider contributing to open source.

Thoughts?

Notes
*1)This is not intended to be a statement for or against the Occupy movement. I'm just trying to be funny. YMMV.
2) Standing out in the Crowd talk from OSCON 2009 has interesting numbers about open source diversity and the benefits it brings
3) I'm willing to help put the slide deck together in my spare time outside work. We could use a Google Docs to allow multiple people to edit it. Maybe the slide deck could provide a list of Eclipse mentors that are willing to help out students fix their first bug, browse the source tree etc. These are details. Let me know if you are interested in contributing :-)
4) This would make an interesting EclipseCon talk. Ten Eclipse committers/contributors you should know and whyKim Moirhttp://email@example.com:blogger.com,1999:blog-25023280.post-24202110025875058892011-11-15T11:18:00.000-08:002011-11-15T18:34:19.839-08:00EclipseCon Europe presentations now availableMy presentations from EclipseCon Europe are now available on slideshare.

The first one is the story of the Eclipse and Equinox team's migration from CVS to Git.

Migrating to Git: Rethinking the Commit

View more presentations from Kim Moir

There were a lot of great presentations on Git migrations such as those by Steffen Pingel and Christian Campo. One thing that I've learned is that the time to migrate is proportional to the size of your code base and history. Someone asked me if we considered just starting in Git without our history. Well, no, but that would have solved a lot of problems. It was also interesting to talk to the EGit team, and meet some of the people working at GitHub. (Thanks for the octocat stickers Kevin!). In honour of Movember, this slide seems appropriate.

Image ©dealingwith, http://www.flickr.com/photos/dealingwith/4295488113/ licensed under Creative Commons by-nc-sa 2.0

The second talk I co-presented with John Kellerman. It's a look back at the last ten years of Eclipse history. I had several people come up to me after the talk and say they really enjoyed it. Thanks! It was fun to look back at Eclipse history and dig up funny pictures and bugs. I enjoyed presenting with John because he talked about the business side and I talked about the evolution of the Eclipse community from a down in the trenches commmiter perspective. A good balance. He has been involved in the Eclipse community since well before my time, lots of great stories!

Has it really been 10 years?

View more presentations from Kim Moir

You can also listen to the talk on FOSSLC website. I love the fact that all the EclipseCon presentations were recorded. I plan to go back to and watch the sessions I missed!

A big thank you to the organizers of EclipseCon Europe for a fantastic conference. I've never attended one before, and was very impressed. Beautiful location, interesting talks, great running paths nearby and of course, the best people. It's great to be able to spend time with people who you work with but never get to see in person, like Ian Bull and Andrew Overholt. It was also great to meet new people at lunch and in the hallways. I talked to some first time EclipseCon attendees who were very impressed with the caliber of talks at the conference so kudos to everyone who presented.

At the IBM booth, we pinned up many pictures of the Eclipse family over the past ten years. It was great to talk to people who visited the booth, especially those new the the Eclipse community. I posted a link to them on my Google+ account. Looking back at them it's amazing to see so many smiling people.

It's hard to believe that it's been ten years. I had a number of people come up to me at the conference and say that they couldn't believe that I had been involved in the community for ten years. Well, I can't believe it either. It reminded me of the moment when I stood up on stage to receive my university diploma and I thought, how could these four years have gone so quickly? I don't know but it's been a lot of fun. By the way, here is a list of other committers who have been involved with Eclipse for ten years or more.

More importantly, there are now over a thousand Eclipse committers today. I'm honoured to work with you all :-)

Presentations on slideshare:
Migrating to Git: Rethinking the Commit
Slideshare: Has it really been 10 years?
FOSSLC recording: Has it really been 10 years?
If you look at the speakers notes, you can see the text of the talk. Most of the slides are just pictures in "Presentation Zen" style.Kim Moirhttp://firstname.lastname@example.com:blogger.com,1999:blog-25023280.post-49385284183432639162011-11-14T05:54:00.000-08:002011-11-14T05:54:42.278-08:00In open source, all you have is social capitalOver a month ago, I watched this keynote by David Eaves that he gave at DjangoCon. Yes, I'm way behind on the list of things I'd like to blog about. I blame Bugzilla :-) Also, quite a few people at EclipseCon Europe came up to me and mentioned that they really enjoyed reading my blog. Thanks - I enjoy writing!

<embed src="http://a.blip.tv/api.swf#AYLUiiUC" style="display: none;" type="application/x-shockwave-flash"></embed>

David Eaves is a negotiation consultant. He helps people on opposite sides of an issue come to an agreement, and has clients in open data, government, industry, and open source communities. He has done work at Mozilla to help manage contributor engagement and implement measures to keep contributors working in the community.

He starts off by telling the story, that as part of of his work with Mozilla, he thinks that he should submit a bug. He submits his first Thunderbird bug and announces on Twitter or Facebook that he's excited to submit his first bug. To which he gets the reply "I bet it's a duplicate". According to this presentation, 50% of all bugs are duplicates. It may be a duplicate, but this response isn't the best approach to encouraging future participation from a new contributor.

He then says that most open source communities don't have financial capital. They don't have money flowing in to influence people. "All you have is social capital". Social capital consists of the people that contribute to your community and make it successful. In theory, in a corporation, human resources tracks how to retain and manage its people. In open source, we spend very little time managing our social capital or even better, tracking it.

He then continues that one of the mantras of open source is that it's a meritocracy and your coding skills are the key to success within the community. But if you look at people who have spent a lot of time in an open source community and are considered leaders, many of them spend a lot more time working with people and managing their community as opposed to coding. To which he says "We pull people in based on their coding skills, and we promote people based on their negotiation skills". Also, he remarks that nobody tells us that, and that we all stress that technical skills trumpet negotiation skills despite the evidence to the contrary.

He then gives examples of funny or misunderstood Mozilla bugs. He states how it's harder to communicate with people when only via the written word. I find that myself. I've met quite a few people at conferences who I've found to be rude in Bugzilla to only find that in person they seem like a totally different person. Reasonable. Friendly. Helpful. Anyways, since Bugzilla is a written medium he suggests that the best way to interact on it is to ask questions. He states that often people just have a solution in mind as a bug fix and aggressively push their solution where in fact they should ask the user what they want to do in the first place. Also, you should paraphrase and repeat what the user said to gain understanding, acknowledge the problem and advocate for a solution. All great advice!

The next section of the talk discusses the architecture of a community. Fork used to be a four letter word in open source But with the advent of GitHub, it's not, but rather a way to empower the user. It also absolves you from seeking anyone's permission before contributing. He says we need to design our communities to "Architect for cooperation and away from collaboration" It's great if a new contributor can start fixing a problem without the transaction costs associated with interacting with a committer. We can spend our time on other tasks. He also states that we need to empower the lowest people on the stack, such as those triaging bugs. He also remarks that immediately marking a bug as invalid without acknowledgement of the effort required to report it doesn't build community loyalty.

GitHub Octocat

Image ©sunfox, http://www.flickr.com/photos/sunfox/4365495446/ licensed under Creative Commons by-nc-sa 2.0

The final section of the talk described applying metrics to the show what is going on in a project. To measure contributor patches from non-paid staff is a way to measure social capital. To determine why people have stopped contributing. To measure wait time for before a patch is submitted. He also states that it would be interesting to have a repository API and once you attach a patch to a bug, it would update the bug with the anticipated wait time, to set expectations for the reporter. He states that Wikipedia segments users based on metrics and they applies actions, such as suggesting mentors for new contributors.

I think having metrics for new Eclipse contributors would be very interesting. I rarely have people contributing patches to my bucket other than from other Eclipse or Equinox project committers, but I'm sure the metrics would be very interesting for other components. It would also be valuable to determine the reason that people stop contributing, and implement measures to encourage people to continue to their involvement.

He finishes by stating that there needs to be a social infrastructure for the community, not just code. Also, in some cases, you many need to remove people from the community to reduce negative social capital. A great talk, I highly recommend it - extremely informative and funny.

Notes:

David Eaves also blogs at http://www.eaves.ca on open data, open source and other interesting topics.
His keynote is here http://blip.tv/djangocon/keynote-david-eaves-5571777Kim Moirhttp://firstname.lastname@example.com:blogger.com,1999:blog-25023280.post-33588711231343242722011-10-31T07:02:00.000-07:002011-10-31T10:23:54.395-07:00Excited about EclipseCon EuropeTen years ago, we were burning the midnight oil getting Eclipse 1.0 ready to release. I offer you proof

Me stuck behind server rack. Yes, I'm wearing COWS shirt. Please don't judge me.

Today, we're working hard to polish our presentations as we celebrate ten years of Eclipse at EclipseCon Europe. I'm excited to have the opportunity to attend EclipseCon Europe, this will be my first time :-)

I've been preparing two presentations over the past few weeks. The first one is called Migrating to Git: Rethinking the Commit. Here, I'll talk about the process we used to convert our large and historic CVS reposository to Git, the problems we encountered, how our development processes changed, and what advice we can offer other teams that are contemplating this migration.

Image ©venegas, http://www.flickr.com/photos/venegas/5549123/ licensed under Attribution-NonCommercial-ShareAlike 2.0 Generic (CC BY-NC-SA 2.0)

Image ©spool32, http://www.flickr.com/photos/spool32/5045502202/ licensed under Attribution-NonCommercial-ShareAlike 2.0 Generic (CC BY-NC-SA 2.0)

The second talk is a light-hearted look back at the past ten years. I received an email from EclipseCon Europe this morning that stated. "After the Stammtisch, a couple of long-time Eclipse enthusiasts present Has it Really Been 10 Years?." Long-time enthusiasts? Okay, that made me feel old. Anyways, in this talk John Kellerman and I look back at the the last ten years and discuss what what we expected when Eclipse was released as open source, the response we received, what mistakes were made, what surprised us. Fair warning: I have uncovered some embarrassing pictures from our past Eclipse family. I'll be using this occasion to showcase them. If you have any interesting pictures to share, email me and I'd be happy to include them :-) My understanding is that a Stammtisch involves beer so I think people will be in the right mood when they walk into the talk.

Last but not least, I invite you for to go for a run or walk each morning at 7am. We'll meet in the lobby of the Nestor hotel. Sign up for EclipseCon exercise here!

See you soon!Kim Moirhttp://firstname.lastname@example.com:blogger.com,1999:blog-25023280.post-66307239622264452682011-10-07T11:30:00.000-07:002011-10-07T11:30:57.649-07:00A history of lizard wrangling and other software storiesI've been thinking a lot lately about open source history. I'm in the midst of preparing material for a presentation that John Kellerman and I will be giving at EclipseCon Europe about the history of Eclipse. Last week an interesting video crossed my twitter feed. It was a talk by Mitchell Baker on the history of Mozilla. Mitchell is the Chair of the Mozilla Foundation and Mozilla Corporation and has been involved in this community for many years. Her title is Chief Lizard Wrangler. That's the best job title I have ever heard. Well, being called an astronaut would be fun too but you get the idea. According to Wikipedia, she's a also skilled trapeze artist. I like learning about people with interesting hobbies.

<p>&amp;amp;amp;lt;p&amp;amp;amp;gt;&amp;amp;amp;amp;amp;amp;amp;lt;p&amp;amp;amp;amp;amp;amp;amp;gt;&amp;amp;amp;amp;amp;amp;amp;amp;amp;lt;a target='_blank' href='http://vid.ly/3p8p5c'&amp;amp;amp;amp;amp;amp;amp;amp;amp;gt;&amp;amp;amp;amp;amp;amp;amp;amp;amp;lt;img src='http://cf.cdn.vid.ly/3p8p5c/poster.jpg' /&amp;amp;amp;amp;amp;amp;amp;amp;amp;gt;&amp;amp;amp;amp;amp;amp;amp;amp;amp;lt;/a&amp;amp;amp;amp;amp;amp;amp;amp;amp;gt;&amp;amp;amp;amp;amp;amp;amp;lt;/p&amp;amp;amp;amp;amp;amp;amp;gt;&amp;amp;amp;lt;/p&amp;amp;amp;gt;</p>

In the video, she talks about the history of Mozilla, which started in 1998. She describes the tension between Netscape the corporation and Mozilla the community. For instance, the belief in the Mozilla community that commit rights should be earned and voted on by your peers, not just assigned based on your employer. It's a really interesting to learn about the conflict in those early years at Mozilla and how they worked so hard with very few resources to be where they are today.

One of my favourite lines from the talk is that "Technology alone does not change people's lives. Our opportunity in the browser is to have a product that touches people." Also, she states that the problem with a lot of open source projects is that they are irrelevant to the marketplace and don't treat their users very well. For instance, calling a user stupid isn't going to make their life better. "You need to make a product that is elegant and beautiful and powerful under the covers but that people love." Mozilla has a bit of a different outlook that the Eclipse community because their flagship product Firebox is used by everyday consumers. Eclipse components are consumed by developers in the form of open source packages that the coordinated release provides, but at the same time many people consume components in commercial products that build upon our open source offerings.

Some other memorable lines "UI is always the most contentious issue". Well, at Eclipse we never argue about UI. Wait....hmm..maybe...this bug has a few contentious comments.....

This talk really resonated with me. Eclipse and Mozilla are two well known open source communities with different histories but ultimately both are very successful. I highly recommend taking the time to listen to it.

Happy Ada Lovelace Day from Ottawa!

Kim Moirhttp://firstname.lastname@example.com:blogger.com,1999:blog-25023280.post-9264730260582009652011-09-01T17:15:00.000-07:002011-09-01T17:20:42.220-07:00Busting Build Myths

Who doesn't love Mythbusters? It must be great to wake up every morning and go to work in a fantastically equipped lab, build things and maybe set off a few explosions. A dream job.

Unfortunately, my lab is filled with aging build machines, not cool toys. When a build explodes I have to pick up the pieces and make it work again. I've never been invited to the White House to talk science while sporting a snappy beret either.

Source Wikipedia: Washington Post blog, credit given to The White House/Chuck Kennedy, The White House/Chuck Kennedy

There are a few myths surrounding builds I'd like to bust. I'll use the only tool I have available to dispel them, my keyboard:

1) My six bundle build is easy. Thus your build is easy too. There is a big difference between building a few bundles and building products, p2 repositories, API tests, tens of thousands of JUnit and performance tests for many platforms. Is running an Apache server in your basement the same as running Slashdot? No. Builds are the same. Scalability issues and complexity.

2) Building with X will solve all your problems. Changing to a different build technology to compile and package your bundles can solve a lot of problems if it has been tested fully and works for all your requirements. But there's a cost to migration. To working out all the bugs and corner cases. Is it worth the transition? Only time will tell. The more complex the build, the higher the cost of migration. Yes, it would be wonderful if we could all run our builds the same way at Eclipse to help our consumers. But this requires a considerable time investment to ensure that everything works. As well, it means forgoing work in other areas to facilitate this transition. It's a tradeoff.

3) Once you get your build working, you never have to change it. As my previous post described, build scripts evolve in concert with the code base. Constantly changing. More code, more tests, more build gymnastics. Building software is like owning a house. You can try to to forgo all maintenance to save money, but your risk long term damage from broken pipes, a leaky roof or mice as the building deteriorates.

Homeowner forgot to visit Home Depot

Image ©graywolfx47, http://www.flickr.com/photos/graywolfx47/4308623603/sizes/z/in/photostream/licensed under Attribution-ShareAlike 2.0 Generic (CC BY-SA 2.0)

4) Nobody in needs to understand how the build works, they just need to push a button. That's great. Until the day before a release when your build fails with a cryptic message about unresolved dependencies. And you have no idea how to fix it. And neither does anyone else on the team.

5) Release engineers are unskilled monkeys. On the weekend, I attended the Software Developer's Summit here in Ottawa. Interesting conference and it was great to meet some new people. In the afternoon, there was a meeting to discuss the long term build support with Eclipse foundation staff and other interested parties. The term "monkey" was used by several participants as a colloquial expression for a release engineer. I don't think it meant to be a malicious expression but at the same time, I found it interesting. Many developers have limited knowledge of how builds work, to them it's a big black box. Monkeys. Big black box. Hmmmm. This sounds familiar.

Let's pretend these apes are monkeys.

Source: Wikipedia. Interpretations of 2001: A Space Odyssey

Since we release engineers understand how the black box works, maybe we're not the monkeys :-)

What other build myths are out there?Kim Moirhttp://firstname.lastname@example.com:blogger.com,1999:blog-25023280.post-12581792619117670672011-08-31T19:16:00.000-07:002011-08-31T19:16:04.190-07:00Research, Release Engineering and ROII recently read some academic papers that quantify some release engineering practices in open source communities. Very interesting.

The first one, "An Empirical Study of Build Maintenance Effort" (PDF), looks at how the time spent maintaining the build impacts the developers in a project. It examines build coupling which refers to the how often changes in source code require changes in build code, as well as build ownership, which is the proportion of developers on the team who are responsible for maintaining the build. The projects studied were ArgoUML, Hibernate, Eclipse (SDK), Jazz, GCC, Git, Linux, Mozilla, PLlot and PostgresSQL.

Here are some snippets I found interesting in this paper. Note that when they refer to "Eclipse-core" they mean the Eclipse project's build. In this paragraph, they are talking about build coupling and how to reduce it

"In Eclipse-core, the coupling is reduced to 16% and in Jazz the observed coupling is a mere 4%. Eclipse-core and Jazz both leverage the automated Eclipse Plugin Development Environment (PDE) build technology. ..... Since the developer must only maintain the high-level build.properties file (via the IDE), the daily build maintenance is reduced".

Thank you PDE family. Dynamically generating Ant scripts at build time to compile and package our bundles makes us look good when compared with other open source projects.

"Other researches have found that the Linux build engineers have spent a considerable amount of time to make their build system as simple as possible for developers, as the expense of a very complex and hard to maintain core build system machinery. "

People always assume that writing software is hard, but for some reason building software should be easy. Build systems are complex beasts and obfuscating the complexity for the user is just as difficult as it might be when writing a full scale application. Writing good software is difficult, and so is constructing an elegant and effective build system. It's just a different skill set.

 "Up to 79% of source code developers and 89% of test code developers are significantly impacted by build maintenance, yet investment in build experts can reduce the proportion of impacted developers by 22% of source code developers and 24% of test code developers."

So it looks like if you hire a release engineer and the productivity of your developers will increase. You would buy a new machine to make the build faster, why not hire a fantastic release engineer and make the build better? The numbers indicate an great return on investment.

Building complexity

Image ©algonquin_college, http://www.flickr.com/photos/algonquin_college/4971004199/in/photostream/ licensed under Attribution-ShareAlike 2.0 Generic (CC BY-SA 2.0)

The second paper of is interest is entitled "The Evolution of Java Build Systems" (PDF).

Again it looks at open source build systems that use either Ant (ArgoUML, Tomcat, JBoss, Eclipse-core) or Maven (Hibernate and Geronimo). The authors find that as the number of source lines of code being built (SLOC) is strongly correlated with the number of build lines of code (BLOC).

"Similar to Lehman's first law of software evolution, build system specifications tend to grow over time unless explicit effort is put into refactoring them."

and

"The Halstead complexity of a build system is highly correlated with the build system's size (BLOC), indicating the BLOC is a good approximation of build system complexity".

Lots of build code means increasing complexity. If you are only building a few bundles, your build is easier to understand. Makes sense.

From their analysis, they concluded found that both Ant and Maven based builds evolved in similar fashion.

I like this sentence

"Despite the crucial role of build systems and their non-trivial maintenance effort, software engineering research rarely focuses in them".

I'd like to thank the authors for conducting this research and look forward to reading more in the future. Build systems are complex systems and I welcome the efforts of these researchers to quantify way they can be improved. And it's extra special when they look at the projects that we work on every day!

References:
It will never work in theory
Queens University Software Analysis and Intelligence LabKim Moirhttp://firstname.lastname@example.com:blogger.com,1999:blog-25023280.post-8984534286918339082011-08-29T12:33:00.000-07:002011-08-29T12:33:17.664-07:00Open source: She loves you, She loves you notWorking in an open source community is great, but there are also some disadvantages. From my admittedly narrow world view as a committer working in the Eclipse community as an employee of a large corporation, here are some of my observations.

Image ©emzee, http://www.flickr.com/photos/emzee/162362897/sizes/z/in/photostream/ licensed under Creative Commons by-nc-sa 2.0

Things I love about working in open source

The people you meet are amazing and enthusiastic. It's is a privilege to work with such a group of talented and thoughtful people.

Instead of non-disclosure agreements, we're free to talk about everything we work on. Since everything is open, there are tremendous learning opportunities. This inherent openness means university researchers write papers about our work. Interesting!

Open source software is used by our consumers in unique ways. When Jeff Norris gave his keynote at EclipseCon 2010 on how Eclipse was used to monitor robots on Mars, it was extraordinary to think that we as a community had contributed to something that was literally out of this world. And when he said thanks to the committers during his talk, it was a very proud moment for us all. There are many other examples of ways in which Eclipse is used to extend our knowledge of the world(s) around us.

Image ©owlbookdreams, http://www.flickr.com/photos/owlbookdreams/3721505610/ licensed under Creative Commons by-nc-sa 2.0

Some things I don't love about working in open source

Many people complain but don't contribute. They consume the code we craft, complain about how its written, but are loathe to roll their sleeves up and write a useful patch.

We are constantly starved for resources, whether it be people, or new hardware. There are too many bugs and not enough days :-)

My gender is an outlier in our community.

Ten years ago this week, I started working in at a small company called Object Technology International (OTI) as a system administrator. I was asked by Jeff McAffer to install a server called dev.eclipse.org that would act as a CVS and bugzilla server for a project that they were going to open source called Eclipse. I said something like "Open source, that's great. Just like Linux". To which Jeff replied along the lines of "Well, I don't think it will be as popular as Linux, but we'll see what happens". And the rest as they say, is history.

What do you love about working in open source?Kim Moirhttp://firstname.lastname@example.com:blogger.com,1999:blog-25023280.post-85850109704977621412011-06-03T13:21:00.000-07:002011-06-03T13:25:02.320-07:00Kill Build: Vol. 1Here are some of the ways I've seen a build killed during my years as an Eclipse committter.

1. Lightning. Ottawa has tremendous thunderstorms in the summer. What also happens during the early summer? Our coordinated release. One summer, a transformer next to our office was hit by lightning. Boom. No power for about 12 hours. Bye bye build.

Image © ViaMoi, http://www.flickr.com/photos/viamoi/3338093351/ licensed under Creative Commons by-nc-sa 2.0

2.  Ice. The air conditioner in our lab filled with ice and ceased to function. The machines in our build lab then overheated and shut down.

3. Flood: Our lab's air conditioner leaked the resulting water and flooded the lab. The build was relegated to a watery grave.

Image © thirsk, http://www.flickr.com/photos/thirsk/840616475/ licensed under Creative Commons by-nc-sa 2.0

4. Random loss of power. A committer plugged in a space heater in her office which tripped a circuit breaker and killed the power in our build lab. Or the total and intermittent loss of power from the Ottawa Hydro. In the end, the results is the same: a dead build.

Image © ViaMoi, http://www.flickr.com/photos/viamoi/3339707547 licensed under Creative Commons by-nc-sa 2.0

5. Hardware self-destruction. The eclipse foundation's power supply for a disk array sparked and brought down the switching gear. Dying switches, UPS's and drives have also wrought havoc.

6. Permission issues: Permissions problems on the filesystem caused committing to the repository to fail. Or the signing process to time out. Or both.

7. Network timeouts aka no network love.

Image © zoso_tc, http://www.flickr.com/photos/zoso_tc/3024964999/ licensed under Creative Commons by-nc-sa 2.0

8. Human Error: The usual suspects compile errors, uncoordinated changes across projects, problems in builder itself, corrupted jars etc. have sent many builds to an early death.

9. Upgrades invoke the unexpected.  Changing a ssl certificate unleashed shenanigans. An simple upgrade of a test machine caused failures.

Image © waferboard, http://www.flickr.com/photos/waferboard/5321533361/ licensed under Creative Commons by-nc-sa 2.0

10. Not respecting resource constraints. Consuming all the disk space, CPU, and bandwidth available is a fine way to finish off a build.

How your builds failed? Any exciting ways I've missed?Kim Moirhttp://firstname.lastname@example.com:blogger.com,1999:blog-25023280.post-74794015065869286602011-05-28T13:24:00.000-07:002011-05-28T13:24:48.380-07:00Looking toward the Indigo finish lineThis week, the Eclipse and Equinox projects released 3.7RC3. For the past month, we have been in end game mode. This means that make release candidates available about once a week, each with progressively stringent requirements to release a fix. All code changes require approval as follows

RC1 - Another committer must +1 your bug before you can submit a change.
RC2 - Two committers must +1
RC3 - Two committers and a component lead must approve.
RC4 - Two component leads must +1 your bug. A component lead can veto your change. Steve Northover coined the term intergalactic approval for a bug fix at this stage of the game.

Image © lrargerich, http://www.flickr.com/photos/lrargerich/4999906554/ licensed under Creative Commons by-nc-sa 2.0

During this entire period, documentation changes can go in without approval. During RC3 and later, all code changes must be announced to our project's release engineering mailing list to communicate to the other committers that you intend make a change.

There are some interesting parallels between the Eclipse end game and long distance running. This weekend, 40,000 runners and 100,000 spectators will participate in Otttawa's Race weekend. The week before their race, athletes participating in the longer distances will taper their runs. In other words, their training mileage drops significantly so that they're well rested for race day.

Image © Gamma-Ray Productions, http://www.flickr.com/photos/29143375@N05/3574211684/ under Creative Commons by-nc-sa 2.0

At Eclipse, the process is similar. We taper our bug fixes as we approach release day. Eclipse is known for it's stable and predictable releases. At lunch yesterday, my committer colleagues remarked that some of their dependencies (not Eclipse projects) just release at regular intervals and and don't have a ramp down process. Other projects release occasionally and then don't have a release for several years. No predictable release schedule. At Eclipse, we are predictable and stable. Some may call that boring, but it allows other projects and products who depend us to consume us at regular intervals. Eclipse 3.7 is especially stable this year given that many committers have been busy releasing innovative new features to Orion and Eclipse 4.1.

We also have weekly test days where the committers and community test the builds and ensure that there aren't any regressions that were recently introduced. For example, here is the PDE team's test plan.

In addition to reducing the amount of changes we release to the build, to ensure the stability of the code base, this tapering of bug fixes and the associated approval process also ensures that other committers have a chance to evaluate our patches. This sanity check ensures that the fixes are both significant enough to warrant releasing to the build at this time and technically correct. I can't speak for other committers, but at this stage of the Eclipse release, we are all a bit tired. So it's good to have several sets of eyes looking at your patch.

Committer after Indigo release

Image © kaibara,http://www.flickr.com/photos/kaibara/4068996309/ licensed under Creative Commons by-nc-sa 2.0

At this stage of the game, only serious bugs are fixed. It's not worth causing ripples within the code to fix a minor bug only to find out after the release is available that this fix had intended consequences.

Image © Marc Dezemery, http://www.flickr.com/photos/mdezemery/295687769/ licensed under Creative Commons by-nc-sa 2.0

What process does your project use to ensure that your code base is ready for release?

Further Reading
Eclipse 3.7 Endgame planKim Moirhttp://firstname.lastname@example.com:blogger.com,1999:blog-25023280.post-25693479240937005672011-03-14T15:13:00.000-07:002011-03-14T19:05:03.108-07:00SDK code coverage with JaCoCoToday, I had to pleasure of closing bug 241254 which has been open for over two years. It was a request to run a code coverage tool against the SDK during the build.

We used JaCoCo which is an EPL licensed code coverage library brought to you by the same team that created EclEmma. Why did we chose JaCoCo?

Help from JaCoCo committers. At EclipseCon 2010, Marc Hoffman (JaCoCo committer) indicated to Olivier Thomann that he was interested in helping us to implement JaCoCo in our build.

Performance. Other code coverage tools made the JUnit tests take significantly longer. Our tests take long enough to finish as it is! Olivier tested JaCoCo and found that it only took the JDT core tests about 2% longer to complete with JaCoCo enabled. Our 68,000 JUnit tests take about seven hours to run in parallel on three platforms. The JDT Core tests comprise 37,000 of these tests, thus we estimated the impact of running JaCoCo during the build would only increase the test run by about eight minutes.

Classes are instrumented on the fly and and remain untouched after the code coverage data is generated. Other code coverage tools require you to instrument the classes for code coverage. Given the huge code base of the SDK, this didn't seem like a feasible alternative.

 JaCoCo reports look awesome.

How did we implement JaCoCo in the build?

Olivier tested an earlier version of JaCoCo and worked with the JaCoCo committers to address some issues. Once these issues were resolved, we opened IPZilla bugs to consumed JaCoCo as part of the Indigo release.

The Eclipse SDK JUnit tests are run with the assistance of a project called org.eclipse.test. An Ant script called libary.xml is used to invoke the test suites for each test bundle. We added the JaCoCo agent and Ant jars to a new library directory of this project.These jars are then added to the extraVMargs property when the tests are run. The libary.xml also specifies the output directory of the coverage data (*.exec files).

When the tests are run, corresponding exec files are created for each test bundle.

We modified the test.xml that is used to run all the tests suites to generate a code coverage report upon completion of the JUnit tests. All the *.exec files are merged into a single file. A coverage report for each bundle in the SDK is run. (excluding Orbit and doc bundles as well as fragments). The Ant for the report generation looks like this:

One problem that we encountered was that that JaCoCo report task was running out of heap space when the source files were passed to it as as zipfileset instead of a fileset. This problem occurred especially when attempting to generate source reports for large bundles such as jdt.core. We overcame this problem by unzipping the source bundles into a temporary location and passing the fileset.

In addition to code coverage percentages, the report generates html of the source files that highlights the code coverage within the code itself. For example:

All this information consumes about 1GB per build. (Sorry Denis and Matt). Thus I have only enabled it for our weekly integration builds, and the data will not be sent to the mirrors.

The code coverage reports for 3.7M6 are now available. Check out your favourite Eclipse SDK bundle!

References
JaCoCo project
JaCoCo mission and design goals
JaCoco Ant tasks
Bug 241254 - run code coverage tool during build
Marc Hoffmans's JaCoCo talk at Eclipse Summit Europe 2010Kim Moirhttp://firstname.lastname@example.com:blogger.com,1999:blog-25023280.post-29805226382583218992011-03-01T12:13:00.000-08:002011-03-01T12:29:16.213-08:00Thoughts on Making SoftwareMy husband (aka Mr. Releng) and I were driving home from his office party in mid-December and had the following conversation.

Me: A publicist from O'Reilly emailed me today and asked if I would like a free copy of Making Software.

MR:  Huh. Why did they offer you a free book?

Me: I don't know. I mentioned to one of my Eclipse colleagues on Twitter that I thought it would be an interesting book to read. Also, one of the editors is Greg Wilson, who's also the editor of the upcoming The Architecture of Open Source Applications. (I contributed a chapter on Eclipse to AOSA).

MR: Next time, mention on Twitter that you'd like a free car. What's the book about?

MR: Free car from Twitter? Don't get your hopes up. The book investigates the evidence that supports common software engineering practices. In medicine, a clinical trial is conducted to see if a new drug has a statistically significant effect compared to placebo or an existing treatment. The same evidence based principles can be applied to software engineering to determine if TDD or Agile methods are actually effective. I've always thought that there was a lot of shouting but scant evidence to support different software development practices.

MR:  Yeah, undergraduate computer science is engineering. Graduate level computer science is math.

From xkcd

As you may have guessed, I'm married to a mathematician.

In addition to being a fan of open source, I also enjoy reading about different scientific disciplines. I love reading scienceblogs and have read many great books over the past year about evidence based medicine. So when I heard that there was a book available that examined what software engineering practices actually work, I was intrigued.

In any case, I finished reading it recently. It was very interesting and I learned a lot! The book is split into two sections. The first section dealt with different research methods. For instance,

How to conduct a systematic literature review

Empirical methods that can be applied to software engineering studies and why software engineering is inherently difficult to measure quantatively.

How to decide on the papers to include in a meta-study.

From xkcd

The second half of the book examines the evidence for different questions in software engineering. For instance:

How do you measure programmer productivity? Are some developers really an order of magnitude more productive than their team mates?

Does test driven development result in better software?

What's the cost of discovering a bug early in the development cycle versus after the product has shipped?

What working environment (cubicles/offices/open concept etc) are the most productive for software developers?

Is there a measurable difference in software quality between open and closed source software?

What are the reasons for the low proportion of women working in the software industry?

Does the use of design patterns improve software quality?

How do mine data from open source repositories for your own studies (Chapter 27 uses the Eclipse project as an example :-)

All in all, I found it a very interesting book that examined the actual empirical evidence to support or refute some of the sacred cows in software engineering. I think this this is a refreshing step forward for our profession. If there aren't numbers to support that the way we work is effective, shouldn't we alter our path to use better methods?

Further reading
Software Carpentry: Empirical results

As an aside, some great books on evidence based medicine are
Bad Science by Ben Goldacre
Trick or Treatment by Simon Singh and Edzard Ernst
Snake Oil Science by R. Barker Bausell

Kim Moirhttp://firstname.lastname@example.com:blogger.com,1999:blog-25023280.post-42131146895511931392011-02-08T12:07:00.000-08:002011-02-08T12:07:16.603-08:00Eclipsing the buildA plan item for 3.7 is to transition the Eclipse and Equinox build process to run on eclipse.org hardware. Why may you ask, isn't this the case today? Two reasons:

1. Until recently, the Eclipse foundation didn't have hardware to support our requirements of running tests on multiple platforms (Windows, Mac, Linux).
2. There wasn't a plan item to transition our build to eclipse.org until 3.7. You may think that we open source developers are happy hippies who have the freedom to work on the bugs that interest them :-). The reality is that I prioritize my bugs as follows:

Fix bugs that cause the build to fail.

Fix bugs that block other committers from moving forward with their work or are necessary for legal reasons.

Plan items

Everything else

I was going to write a post describing the progress migrating to eclipse.org hardware but I thought it would be a good idea to give you some background regarding how the Eclipse and Equinox project's build works today.

The Eclipse build creates SDKs for 15 platforms.

A graphical representation of the 15 platforms we build (os,ws,arch)

We use fragments to define platform specific code that is associated with a host bundle. In some of these fragments, there's C code that needs to be compiled on the platform specific hardware to create binary libraries. For instance, the SWT and equinox launcher fragments are examples of these artifacts. We have about seven machines to compile the libraries for these 15 platforms, as some are cross compiled. The SWT and Equinox team have hudson instances, which connect to all these internal IBM servers, compile the C code, and commit the resulting libraries in binary form to CVS at eclipse.org. This part of the build isn't transitioning to eclipse.org.

A simplified description of the existing Eclipse build that produces the artifacts that are available for download on eclipse.org is shown below. Essentially, once a build is launched from cron, the build scripts check out all the code from eclipse.org to the IBM build machine which compiles the bundles. These bundles are copied to eclipse.org to be signed, then copied back to the IBM build machine to be assembled into a p2 repo, from which we create SDKs to run the tests. The zips, repos and test results are rsynced to eclipse.org.

Once we get the issues worked out with the new Hudson slaves to run tests, all the JUnit tests will run on eclipse.org hardware. Eventually, we hope to run the performance tests there once we have sufficient hardware.

Advantages of moving the build to hudson.eclipse.org

The build process will be more open and other Eclipse and Equinox committers will be able to start a build. Today, I manage the crontab of the build machine.

Fewer issues with network timeouts due to the fact that the eclipse.org filesystem is local to Hudson.

Hudson has a rich feature set and many plugins to extend it.

Disadvantages

Like kindergarten, we'll have to share the filesystem and machines with others. Today the build runs on dedicated machines and thus we don't have resource constraint issues from other teams. (The build process itself isn't faster at eclipse.org because of these resource constraints, but the tests are because at the moment we are the only team using the Windows and Mac test machines.)

Can't hack and slash the build on the the command line to rerun a single test suite or restart the build manually.

In a future post, I'll describe the process to transition our builds to run on eclipse.org and the obstacles that we have overcome.

How can you help? Consider donating to Friends of Eclipse.

References

Build at Eclipse.org

Graphics thanks to open source clip art

Servers
Database
iMac
Server cabinet
Tower
DatabaseKim Moirhttp://firstname.lastname@example.com:blogger.com,1999:blog-25023280.post-21213915307571939592011-01-28T12:20:00.000-08:002011-01-28T13:34:55.791-08:00Implementing shared licenses with 3.7M5This is the best Eclipse license I've ever seen.

Image © chriscardinal, http://www.flickr.com/photos/disatasu/3243844762/ licensed under Creative Commons by-nc-sa 2.0

Conversely, dealing with license files in Eclipse features is a bit painful. Today, each time the Eclipse license changes, you need to copy the new license files to your features. The license files included in the Eclipse SDK are highlighted below:

These same files are included in the 46 features that the Eclipse and RT Equinox project builds. This is very tedious to update when the license files change. Lots of copy and paste. The license text also appears in the feature.properties.

In Eclipse 3.7M4, the PDE and p2 teams added support for shared licenses.

The license files will be copied from the license feature to the feature that refers to it. In 3.7M5, I modified our features to use this shared licenses. For instance, the beginning of the feature.xml for the Eclipse SDK now looks like this:

To implement this, I followed these steps.

1. Create a license feature. This feature doesn't include any bundles or features. It only stores the license files which its build.properties reference. The feature.properties has only two properties - the licenseURL and license.

2. Update the existing features to reference the license feature. Remove the license files from these features. Remove the references to the license files from your feature's build.properties. The values will be inherited from the build.properties of the license feature. Remove the name and values of licenseURL and license from the feature.properties. These will be included from the license feature. Ensure that you don't have duplicate properties in the feature.properties of the license feature and feature your are updating. This will cause a build failure.

3. Update your map files to include to the new feature. You don't need to nest the feature in another feature to fetch it, this happens automatically. For example, this is where our license feature is located

firstname.lastname@example.com=v20110121,:pserver:firstname.lastname@example.com:/cvsroot/eclipse,,org.eclipse.sdk-feature/features/org.eclipse.license

4. Run a test build. Fix typos until you have a clean build. Verify that all your features still include the appropriate license files.

There isn't an IU for the license feature included in the p2 repository. The license text is included in the metadata.

Note that you'll need to build with 3.7M5 bundles. There was a bug in the 3.7M4 bundles that prevented shared licenses from working in generated source features.

The advantage of this approach is that when the license files are updated, we'll only need to update the license feature. We'll also have to increment the versions of the license feature in the referring feature, but that's a simple search and replace.

Some other implementation details: I could have also stored the copyright information in the feature.properties of the license feature. However, the copyrights of our features are not identical, so I didn't choose this approach. This may be useful for other teams.

Thanks to the PDE and p2 team for implementing this!

Further references

Bug 306818 - Improve license support in p2.
License mechanism description in wiki
Bug 332662 - Adopt new feature that allows to share the license fileKim Moirhttp://firstname.lastname@example.com:blogger.com,1999:blog-25023280.post-40584731487175383402011-01-24T13:02:00.000-08:002011-04-22T08:22:39.980-07:00Revert to an earlier p2 profile from the command lineToday, we're running builds toward 3.7M5 for the milestone that will be available Friday, January 28. This morning I updated to our latest integration build from the repository. Unfortunately, one of the bundles had a compile error which was serious enough to cause Eclipse to crash on startup.

If you want to revert your installation to a previous version, this is easy to do from the UI. Chris describes this here.

However, if you can't access the Eclipse UI, reverting becomes a bit more complicated. The online help illustrates how to use the p2 director application to revert your install to a previous profile state.

The list of profiles available in your Eclipse install are located in your profile registry. The highlighted profile id below reflects my working installation from last week.

To revert to this profile, I downloaded a new build, extracted it to a directory and ran the following command

C:\N20110122-2000\eclipse\eclipsec.exe -application org.eclipse.equinox.p2.director -repository http://download.eclipse.org/eclipse/updates/3.7-I-builds -revert 1295719004390 -destination c:\I20100309-0809\eclipse -profile SDKProfile -bundlepool C:\I20100309-0809 -p2.os win32 -p2.ws win32 -p2.arch x86

Operation completed in 68759 ms.

My install was reverted to the previous profile and I could once again start Eclipse.Kim Moirhttp://email@example.com:blogger.com,1999:blog-25023280.post-38155419917879743402011-01-19T17:31:00.000-08:002011-01-19T18:39:51.848-08:00Hudson best practices and Eclipse

One of the plan items for Eclipse 3.7 I've assigned is to migrate the Eclipse and Equinox build to run on the Hudson installation at eclipse.org. So I've spent a lot of quality time with Hudson lately. (Soon to be called Jenkins).

Today, I attended a webinar about optimizing Hudson in production hosted by Kohsuke Kawaguchi of CloudBees. Since my handwriting is similar to the last slide in this Oatmeal cartoon, I thought it would be better to jot my notes down in a blog post. As I was listening to his suggestions, I thought about how his seven best practices apply to our use of Hudson at Eclipse.

1. Backups

Backup your Hudson install to protect from disaster and accidental configuration changes.

Image © davemorris, http://www.flickr.com/photos/davemorris/2395980976/sizes/z/in/photostream/ licensed under Creative Commons by-nc-sa 2.0

$HUDSON_HOME on the master stores everything that needs to be backed up. The slaves doesn't need to be backed up.

Live backups are fine as configuration changes are atomic

In addition to the backup of the configuration, a backup of the filesystem is necessary to provide consistent snapshot.

Backups are great but can you restore? On a regular basis, try restoring your hudson configuration and starting up a test hudson instance with the restored hudson.war file.

2. Disk

Prepare for disk utilization growth

Space is more important than speed when ordering new drives

Plan for expandable disk volumes

If it's too late, symlink is your friend

3. Use native packages

For instance, *.deb, *.rpm. Easy to update and install, and they include init scripts.

Configuration is stored in /etc/default/hudson and /etc/sysconfig/hudson

 Existing $HUDSON_HOME can be migrated

Native Windows package is a work in progress

@Eclipse: Backups and disk configuration are managed by the webmasters, along with upgrading and installing hudson.

4. Distributed builds

You will grow beyond a single system

Increasing load on a single machine is not the only issue

It's cheaper to grow horizontally (additional machines) versus vertically (more memory and CPUs on a single machine)

It's also good to have isolation between build processes in case you want to diversify the test and build platforms

Let master launch slaves via SSH or DCOM. This makes it easier to keep the cluster up and running.

SSH public key authentication makes it easy to connect to slaves on disparate platforms.

@Eclipse: Yes, we have distributed builds and several platforms available for test purposes.

5.  Labels

Treat build machines like livestock, not like pets

Image © davegroth, http://www.flickr.com/photos/davegroth/9107888/sizes/m/in/photostream/ licensed under Creative Commons by-nc-sa 2.0

Build machines should be interchangeable

Don't tie builds to a specific build machine, unless there are platform limitations. This approach will yield better resource utilization and less downtime. Queued builds can use the next available machine instead of waiting for a specific machine.

When using labels for your Hudson slaves, name them to reflect their capability. For instance, if the slave is Mac or Windows hardware, the label should reflect this.

If there is a real reason to limit build to run on a single machine (such as wanting to run platform specific tests), tou can use boolean expressions with labels. For instance, this Hudson job shouldn't run the slaves running Mac or Windows

@Eclipse: We use label our build machines as livestock. No pets for us. However, I'm quite envious that the Mozilla foundation has adopted red pandas (firefoxes).

 6. Invest in a good URL

By default Hudson runs on port 8080. This is difficult for users to remember.

Use the host's alias instead of the machine name. Thus if the machine names changes, the users won't have to go to a new URL.

Share port 80 with other applications using Apache reverse proxy with which will also allow you to run Hudson as a non-root user.

@Eclipse: https://hudson.eclipse.org is short and simple.

7. Try to keep the build records under control.

Discard old build records if you can

Removing old builds reduces start-up time and memory usage.

Settings are on a per-project basis. For instance, here are settings for one of my Eclipse builds.

@Eclipse: Yes, we do clean up old builds. Also, the webmasters have created a cron job to send a friendly email every week listing of the Hudson disk utilization to remind the release engineers to clean house.

The slides are available here and obviously provide a lot more detail than my short summary. If you're interested the best practices for configuring Hudson for a production environment that has room to grow, this presentation is provides very useful suggestions.Kim Moirhttp://email@example.com:blogger.com,1999:blog-25023280.post-21105689967038065682011-01-14T06:44:00.000-08:002011-01-14T07:09:19.416-08:00Smashing open source stereotypesThe Wall Street Journal published an article yesterday where it described the open-source software movement, whose activists tend to be fringe academics and ponytailed computer geeks. This is one of the many unfortunate stereotypes surrounding open source that I've heard over the years. Let's break some of those down.

1. Open source is a fringe movement.

Open source builds mainstream software. I work all day long contributing to open source software, as do many of my colleagues. Why do corporations pay us to contribute to software that doesn't have a price tag? It's in their self-interest to have employees improving the open source software that underlies their commercial offerings. Here are some of the fringe groups involved in Eclipse.

Source: Eclipse Foundation Members' Meeting Q4 Update December 16, 2010

These unknown companies are members of the Linux foundation.

2. Open source is not professional.

At Eclipse, we ship our software on time every year. We've done that for seven years. That's professional.

 Source: Ian Skerrett: The Helios Train has arrived

3. Open source contributors are loners sitting in their parents' basement working on arcane bugs.

Nope. Open source is very social. We interact on IRC and twitter. We attend democamps, learn about new projects and build new businesses. We speak at conferences. The software we work on makes a difference in the world. It helps monitor robots on Mars, manages trains in Switzerland and models chemical reactions.

Source: Madhu Samuel: Eclipse Democamp Bangalore 2010

4. Open source developers aren't in good physical condition and don't have interests outside of work

Again, a stereotype that has been proven wrong. We ran 570K at EclipseCon 2010.

Open source contributors run marathons, bike, curl, swim and play soccer or hockey. In fact, you can order an Eclipse bike shirt.

We also volunteer at schools and raise money for charity.

5. Open source contributors are always male.

Source: Miriam Ruiz: Women in Free Software

Wrong again.

We may be a small minority, but here's hoping that these fine female role models will inspire a younger generation of women to consider the amazing career opportunities that open source has to offer. Two generations ago, female doctors were rare. Today, women are over 50% of new Canadian medical school graduates. So, may borrow a phrase from a recent campaign, it will get better.

What other open source stereotypes would you like to smash?Kim Moirhttp://firstname.lastname@example.com


text:
Whatever They Told You About How Hard Is Discrete Math Is Dead Wrong…And Here's Why
The New Fuss About How Hard Is Discrete Math
The history of discrete mathematics has involved several challenging issues that have focused attention within regions of the area. Discrete math is just one of the main elements of mathematics. Normally, Numerical Analysis is an amazingly extensive subject, and it studies a lot of distinct sub-fields that are crucial in solving numerical real life difficulties.
The remedy is a Free Company that may be contracted to work on projects collaboratively through the space. Indeed, since the video demonstrates, such modeling has long been part of classic math programs including Singapore Math. Lastly, the model should be used or served somehow.
According essay-company.com to systems theory, the one thing you are able to do is to irritate a system. There are many explanations as to why the mathematics is essential for machine learning. The goal in machine learning is to lessen entropy.
Failure is a significant portion of innovation and an essential step in the quest for excellence. The discussion section offers you a chance to ask questions regarding the lecture material. You shouldn't be surprised to observe problems very similar to these on the last exam.
A superb comprehension of math is essential for every computer scientist, and the math requirement is starting to become more diverse. The grading is quite fair. If you're passionate about what you're doing, you will explore various varieties of software only for fun, and that is going to supply you with far more experience and techniques, than your less motivated peers will have.
Each integer program may have many distinct formulations. The straightforward substitution cipher is quite simple to break. http://www.bu.edu/trustees/secretary/ A minor in mathematics is also feasible.
Graph Networks are a wealthy and important region of graph ML. The practice creates a modified logarithmic curve referred to as a logistic. Whereas abstract machines are simple to understand and quite ideal.
It's very important to your understanding to take a good look at Figure 2B and 2C. The math paper of the SATs has a rather large part specializing in discrete math. Quizzes could be given at any moment.
Lies You've Been Told About How Hard Is Discrete Math
To pick out the best algorithm to repair a particular problem, you've got to have the capability to determine the efficiency of various algorithms. The idea of quantum parallelism is powerful and not tough to comprehend. This algorithm returns numerous complex numbers which is later employed for point-wise multiplication.
The ROC curve is among the very first tests used when modeling with the majority of algorithms. Ordinal measurement was made to infer conclusions, although other methods are utilised to spell out conclusions. Don't get in that conversation about conjugate priors, but should you do, be confident that you're going to chat about the beta distribution, since it's the conjugate prior to most every other distribution mentioned here.
When you iterate data, you should work out the slope with respect to each weight. essay writing service Sunk cost is this kind of unflattering term. No matter in which you place your threshold.
Broadly speaking, autoencoders are neural architectures which take an object as input and attempt to return the exact object as output. To understand the reason, you should know about the idea of convexity in optimization. In other situations a model is produced for internet prediction.
A lot of the topics are covered from several perspectives and with different verbiage, lots of the theorems are supplied with various proofs. Numerical analysis offers an important example. Probability density function or pdf can be utilised to compute the probability of a particular observation in a distribution.
The Ultimate How Hard Is Discrete Math Trick
Any student who feels he or she might require an accommodation based on the effects of a disability should contact me privately to talk about their particular needs. Program implementation isn't a part of cake and, occasionally, demands a level of clout to get things done. These topics are vital in having the ability to understand different rules in games like baseball.
As soon as it's a fact that the web has exhibited immense rise and success over the last few decades, the technology supporting the web is ripe for disruption and innovation. All the connected sensors that constitute the Internet of Things are like our bodies, they supply the raw data of what's happening in the world. If you're looking for note taking app, Magic Note Pro is appropriate for you.
You have to present your work on all difficulties. From time to time, problems are excessively challenging to solve optimally and we just need to come across a quick solution. Don't wait until the limit to discover that you own a performance issue.
Thus, the likelihood that the entire set of computable functions could be placed into place by any true brain are zero. To have the capacity to spell out a real-world phenomenon To be able to predict what's going to occur later on. Given the present state, the optimal decision for every one of the rest of the states does not rely on the preceding states or decisions.
The thing is you may have an issue, and should you know that it can't be solved, that's perfect. Math for a whole lot of people is a massive scary monster. A great deal of the ideas you're have won't progress the area.

subset: commoncrawl


text:
Austin FC will become the 27th MLS team in 2021, league commissioner Don Garber announced on Tuesday.
Austin will play in a new $225million stadium and will be Texas' third MLS side, joining FC Dallas and Houston Dynamo.
However, Austin will become the city's first team in a major professional sports league.
"Austin is a thriving metropolitan city – the personification of what we mean when we say MLS is a 'League for a new America,'" Garber said in a statement. "We are extremely proud to be the first major professional sports league to become part of the culture of this historic American city."
"This is a historic day for Austin, as MLS becomes the first major league to plant roots in our beautiful city," Adler said. "We believe professional soccer will bring a great and especially needed benefit to our city."
Other expansion teams that have yet to make an MLS debut will be located in Cincinnati (2019), Miami (2020) and Nashville (2020).


text:
Get started
Bring yourself up to speed with our introductory content.
Windows Server Clustering
Cloud-based email security tools barricade entry to Exchange
The pressure is on Exchange administrators to avoid a ransomware outbreak that cripples the on-premises email system. Cloud-based security tools can help blunt trending attacks. Continue Reading
Azure AD B2B offers a secure way to grant external access
Organizations that open up their resources to external users can restrict access using the Azure AD B2B service with minimal effort on the part of the administrators. Continue Reading
PowerShell 6 expands reach but lags behind Windows version
Cross-platform PowerShell arrived without all the functionality that's available in Windows PowerShell -- but it brings the ability to manage Linux and macOS systems. Continue Reading
Using Microsoft Exchange certificates requires planning
Exchange certificates typically require minimal management effort after they have been set up, and they offer a secure means of communication between different organizations. Continue Reading
Creating PowerShell scripts for task automation
At a certain point, administrators who run PowerShell commands from the console will find it more efficient to develop a script that does not require manual intervention. Continue Reading
Windows Defender Credential Guard secures login data
Windows Defender Credential Guard uses virtualization to isolate access to domain credentials and diminish the threat of attacks based inside the data center.Continue Reading
CLI vs. GUI: Find the right admin tool for various scenarios
Standard Windows and Linux command-line utilities oftentimes have niche, yet important functionality not available in GUI tools that require IT workers to make custom workflows.Continue Reading
These PowerShell script examples help tidy up code
Even the most grizzled scripting veterans might learn some new PowerShell tips and tricks to tighten their automation code or produce clearer error messages.Continue Reading
What DPM monitoring options are there?
Administrators tasked with checking the status of System Center Data Protection Manager have a few choices, some of which are better suited for larger DPM deployments.Continue Reading
Microsoft SCOM (System Center Operations Manager)
Microsoft System Center Operations Manager (SCOM) is a component in the Microsoft System Center suite of enterprise management software.Continue Reading
Future of Windows might involve significant weight loss
The influence of containerized applications could sway Microsoft to introduce more far-reaching refinements to Windows Server and reduce the OS to the bare necessities.Continue Reading
Five system administrator skills Windows admins should hone
IT workers need to learn how to ride the wave of innovation and master these five technologies related to Windows Server that can ease their workload and help the business.Continue Reading
Options for server management tools expand to meet IT needs
Not only do admins have to contend with a mix of server OSes, there are diverse scenarios to complicate their management. Learn about the tools worth exploring for administration.Continue Reading
How do I build data protection policies in SCDPM 2016?
One size does not fit all when administrators develop a protection policy for specific applications. Learn about the configuration options in System Center DPM 2016.Continue Reading
New Office 365 administrators grapple with challenges
More enterprises mulling the move to Office 365 should factor in the adjustments necessary to get the IT department up to speed to manage the platform properly.Continue Reading


text:
Name: Black eyes self titled
File size: 668mb
Language: English
Rating: 10/10
Black Eyes was a post-hardcore band from Washington, D.C. that existed from August to Black Eyes' self-titled debut album was released on April 15, through Dischord Records. Most tracks featured the band's trademark dual . A short-lived band that made a huge impression on post-punk, experimental hardcore, and indie music, and still feels fresh due to. Find album reviews, stream songs, credits and award information for Black Eyes - Black Eyes on AllMusic - - Black Eyes self-titled debut displays a band.
Black Eyes self-titled debut displays a band with a hold on the experimental side of D.C. punk -- a path paved by Fugazi and, particularly in this case, Q and Not. 4 Sep - 5 min - Uploaded by SoulAuctioneer from their self-titled debut on Dischord Records. Black Eyes, an Album by Black Eyes. I expect that in a way similar to his work on Rites of Spring's fantastic self-titled LP, Ian MacKaye (of Fugazi and Minor.
Find a Black Eyes - Black Eyes first pressing or reissue. Complete your Black Eyes collection. Shop Vinyl and CDs. Find a Black Eyes - Cough first pressing or reissue. Complete your Black Eyes collection. Shop Vinyl and CDs. 14 Dec The Black Eyes' debut self-titled album has proven to me something that I did not believe in the past. I was a strong believer that first. 14 Jan Anyway, when BLACK EYES released their first self-titled album on Dischord I was totally blown away. It's really not for everybody, but at the. S/T by Black Eyes, released 01 April 1. Someone Has His Fingers Broken 2 . A Pack Of Wolves 3. Yes, I Confess 4. On The Sacred Side 5. Nine 6.
22 Jan Releasing their absolutely stunning self-titled debut in , the band With each song on Black Eyes grabbing the listener and never letting. 16 Dec They branched out into more experimental territory on their second record, " Cough", but I can't recommend the self-titled record any more. Here you can download black eyes self titled shared files: Boys With Xray Eyes Self Titled ().rar from childlitunjournal.com MB, dear black diary - (self-titled) . 29 Nov When Washington, DC's post-hardcore quintet Black Eyes New York's Rough Trade a few months after the release of their self-titled debut.


text:
August 31, 2015
Hubbards Farmers Market
We'll be at the Hubbards Farmers Market (at the lovely Hubbards Barn) on September 5 and 19.
Market hours: 8 a.m. to Noon
Etsy Made in Canada 2015
Tire Swing Naturals and about 80 other makers will be taking part in the Halifax's second annual Etsy Made in Canada sale on Saturday, September 26. The downtown Halifax venue has yet to be announced – stay tuned!
June 14, 2014
Tire Swing Naturals' Products Now Available at Fiddleheads Kids' Shop
Local baby and kids' store, Fiddleheads Kids Shop has begun to carry several Tire Swing Naturals products at its two Halifax-area stores – one located on Prince Albert Road in Dartmouth and its newest location on Nine Mile Drive in Bedford. The great staff at Fiddleheads have chosen our products that will best meet the needs of their clientele – our mom and baby products and favourites like our lip balm, bug spray and, of course, Calm Balm. Many thanks to everyone at Fiddleheads for supporting local businesses and working so hard to bring its customers safe, affordable products.
Check out our new blog, The Dirt !
I really do love to share and support community efforts whenever I can. I'll happily donate one gift basket a month to be used as an auction item or prize for a non-profit organization.
Please email me with your request and provide the following details: name of organization, type of fundraising activity, date of event and deadline for the delivery of the donation. Because I'm a teensy shop I can't accommodate all requests but will do my best to support as many projects as possible.
Past projects:
Zuppa Theatre Co.
Camp Triumph
Breast Cancer Action Nova Scotia


text:
Soft Touch Leather Cleaner and Conditioner
$40 per bottle
Soft Touch Leather Cleaner and Conditioner can be used to clean and condition finished leather furniture. This product will also work for finished leather auto seats and many other forms of finished leather coverings. Soft Touch Leather Cleaner and Conditioner is the best product for do-it-yourself cleaning.
Order Form
If you would like to send your garment for service, simply fill out the blanks in the form below and click on SUBMIT button. You will then receive an order confirmation, along with full instructions and further information. Print out the coupon below and submit it with your order, and you will also receive Water Resistant FREE, just for sending your order directly to Ram Leather Care.
Print out this coupon and send it in with your garment, and you will receive free water resist:
|©2018 Ram Leather Care : 8720 St. Charles Rock Road, St. Louis, MO 63114
call 314-429-5115 or toll free at 1-800-5-ASK-RAM