Thursday, February 28, 2013

Yahoo Remote Worker Observations

On Mayer@Yahoo decision to rescind work@home assertions by commenters and authors:

  • Not done immediately.  Must have been resulted from data-driven analysis.
  • Cannot be applied case-by-case because it would hurt morale or be too difficult
  • Must be for better innovation practices based on past experience
  • Must be for better productivity practices based on past experience
  • Company is in trouble so they must do big disruptive stuff
  • She is CEO, that is a good enough reason
  • Merely a ruse to get dead weight to quit then they will let best workers work remotely at some point in the future
  • She is smart

  • She is applying past business practices based on past experiences
  • It is generating a lot of news articles about Yahoo

  • A blanket policy cannot represent smart policy
  • Punishment over Incentive is demoralizing
  • This shows lack of trust
  • Remote employees are more effective (also stated with some or many)
  • Office employees are less effective (also stated with some or many)
  • She is encouraging people to quit to reduce/eliminate coming layoffs
  • She is controlling
  • She is stupid

From my view, I don't think any of us can really know why she implemented the policy.  Publicly stated agendas might not be private agendas. As a CEO, she needs to walk a pretty tight line to make sure she does not dramatically negatively effect share price of Yahoo.  Most of the above assertions imply a lot of inside knowledge and what the real motives are.

Although I am just giving another opinion I just thought I would throw in my 2c ant point out what I think are difficult to deny outcomes:

  1. Current remote workers will dislike/hate this policy
  2. A portion of remote workers will have to quit due to location and/or social situation
  3. Many in-demand remote workers who dislike this policy will change companies in the next four months.
  4. An unpopular decision by management has some demoralizing effects
  5. Yahoo is being talked about a lot right now

4 and possibly 5 of these are negative outcomes.  The fifth might actually magnify the first four for employees.  For this to be a good decision these all have to be outweighed by other positives.  I tried to think of the immediate positive outcomes and I could not think of anything really obvious (yahoo is doing something to change course -- maybe?).  That does not mean this won't work out as a policy (my personal feelings aside), but I think it does explain the dogpile of negative comments on the articles about Yahoo.

Monday, January 16, 2012

Workaround for Ruby support on Netbeans 7.1

Firstly, I messed up. I should have had community-ruby ready for NetBeans 7.1 general release. For all the problems I created for you all, I apologize.

Secondly, The main issues with getting a good release of community-ruby in the catalog for NB 7.1 are:

  1. -- Some infrastructure broke which makes it impossible to release at the moment. This may seem like the big problem but in fact….
  2. Netbeans 7.1 updated some components (as software is known to do). One of those components was html.editor.lib. Ruby support was dependent on version 1, but NetBeans 7.1 only ships version 2 now. This is the main reason why the Ruby support from 7.0 is un-installable on 7.1.
I have addressed item 2 enough already to make it installable on NetBeans 7.1. In fact, so far I have:

  1. Updated internal JRuby shipped to (from 1.1.4). It also means update JRuby internals for pieces of community-ruby which depends on JRuby internally. This is a good thing for the future of community-ruby. On top of that, it also gave me a really good idea of what we need to change in JRuby itself to help make JRuby more modular.
  2. Updated community-ruby to compile on Java 7
  3. Changed some no longer compilable unit test base classes to again compile. yay. Unfortunately, there are some regressions to be fixed. But we now have ci builds generating reasonable results again.
If you are interested in installing what I am calling preview1, then grab the preview zipfile. Once you have this file, unzip it (note location) and then within Netbeans 7.1 you can:

  1. Select Tools->Plugins from menu
  2. Select Downloaded tab
  3. Press Add Plugins...
  4. Navigate to where you unzipped the nbms files
  5. Select all files which end in .nbms (you can do this all in one selection but if you include any non-nbms file it greys out the open button)
  6. Accept and install…
Hopefully by the time 207075 is fixed, I will have things greener on the ci builds and also have the dreaded Rails hanging bug fixed. For tracking the official release of community-ruby you can watch bug 207025

Thursday, May 12, 2011


Announcing Purugin (プルギン)!

Purugin is a Ruby-based plugin framework for Minecraft which is written on top of Bukkit.


Minecraft is a fun game by itself. If it stayed the way it is today, then people would continue enjoying Minecraft for a long time to come. However, all players are critics and all players love the ability to change things in a game here and there. Since Minecraft is written in Java, many plugin initiatives have sprung up to allow just that. The sheer number of mods available for the game is staggering. In looking at the source of several of these mods one thing which struck me was....Damn! I would rather write these things in Ruby. Fortunately, JRuby exists...

Purugin is written using JRuby and it layers on top of Bukkit. Bukkit is an API which maps to the obfuscated Minecraft APIs and it also provides many conveniences for writing server-side plugins. The Bukkit API by itself is not particularly tough to use, but because it is Java and because it cannot make use of blocks/closures it ends up having more syntax/ceremony than what you can do in a Ruby syntax. Purugin is a Bukkit plugin which allows you to register plugins written in Ruby. Yay....

Getting Started

(Note: This assumes you have purchased and installed Minecraft already...kind of tough to mod a game you don’t actually have ;) )

In order to install Purugin you must first get CraftBukkit. CraftBukkit is a companion piece to the Bukkit library which manages Minecraft servers. Install CraftBukkit (instructions) and then get a copy of Purugin.jar and place it in your CraftBukkit plugins directory. Now also put in an example Purugin plugin player_joined.rb into the plugins directory as well. Finally, you need a copy of jruby-complete.jar ( at the root of your CraftBukkit directory. Once you have did all this your CraftBukkit dir should now have these things added to it:


Now startup CraftBukkit:

java  -Xms1024M -Xmx1024M -cp jruby-complete-1.6.1.jar:craftbukkit-0.0.1-SNAPSHOT.jar org.bukkit.craftbukkit.Main

When it starts you should see the console come up and you will see a couple of noteworthy lines:

17:38:36 [INFO] [PuruginPlugin] version 0.1 ENABLED
17:38:36 [INFO] [PlayerJoined] version 0.1 ENABLED

So, at this point if you run Minecraft and enter the Multiplayer game at localhost (or whatever host you are running your server), you should see the message: Player {your_name} has joined.


Let’s look at the source for the player_joined.rb plugin:

purugin('PlayerJoined', 0.1) do
def on_enable
# Tell everyone in players world that they have joined
event(:player_join) do |e| do |p|
p.send_message "Player #{} has joined"

# Tell everyone in players world that they have quit
event(:player_quit) do |e| do |p|
p.send_message "Player #{} has quit"

Just scanning down this source I think it is fairly obvious how your were sent the Player joined message. Let’s example a few other aspects of writing any plugin. For starters there is a purugin method. This method contains the name of the plugin and the version along with a block which is the logic for the plugin. Using a block-based method for this stuff is sometimes inadequate since block scoping is a little more limiting than defining a class. For a more traditional definition using a class look at I prefer using the short method-based definition up until the point it becomes a pain. For short plugins like this the method-based definition makes the plugin that much more concise. To each their own...

The next interesting bit is the lifecycle method on_enable. There are three lifecycle methods you will be concerned with: on_load, on_enable, and on_disable. You can refer to Bukkit documentation for the exact definition, but I think they are fairly intuitive. For most people you probably will only use on_enable. on_load will sometimes be used if you want something loaded before any plugin in the system has been enabled.

Inside of on_enable you will typically register events. In this case, we register listeners for :player_joined and :player_quit, but there are many many many events that you can register. You can monitor virtually anything. See the examples directory in Purugin’s source for more. [Note: :player_joined or any event name is not actually a symbol in Bukkit. This is Purugin trying to make the API look a little cleaner. At this point the documentation for Purugin is lacking, but the source is fairly small and tables for events or block types will not take long to find. Please consider helping me document things via rdoc patches of documentation on the wiki associated with this project].

Early Days

At this point, I have made a small collection of examples that are included with the source. I recommend looking at these as a way to get started. commands.rb is a plugin for registering commands. locs_plus.rb is a plugin which uses commands.rb for registering it’s own commands. ports.rb is a simple teleporter plugin (out of specially marked signs) which shows how to look at blocks.

Over time, I (someone) will make some more guides and help flush out the API better. This is a very humble start with an API I knew very little about. Expect change and perhaps help facilitate that change via Github issues and pull requests (or editing the wiki).

Monday, May 2, 2011

Installing Ruby support on Netbeans 7.0

This is a quick entry (with pictures!!!) on installing Ruby and Rails support on Netbeans 7.0. As you will see it is very easy to do if you have ever installed a plugin beyond your initial Netbeans install.

So you startup your freshly installed Netbeans and you see this:

At this point you want to select Tools -> Plugins:

This will pop up the plugins manager in Netbeans. Click on the ‘Available Plugins’ tab and click check box for ‘Ruby and Rails’. Then hit ‘Install’ button at bottom of manager:

Now you need to click through the install process. Click Next:
Click ‘Continue’ (The certificates are all self-signed and unfortunately you get this message, but it is ok):

After this you select ‘Finish’ and then you need to restart Netbeans:
At this point you can pat yourself on the now have Ruby and Rails support in Netbeans 7.0.

It should also be fairly obvious that you this entry walks you how to install any plugin (*hint* *hint* - like the git plugin) in Netbeans. Enjoy!

Friday, February 18, 2011

Installing Ruby support in NetBeans 7.0 Beta 2

NetBeans 7.0 Beta 2 is the first release where Ruby and Rails support does not show up as an available plugin choice. Until we have our first community release, you can follow these steps to update your plugins list so you can still add Ruby support to NB 7 Beta 2:

  1. Click Tools -> Plugins
  2. Click on 'Settings' tab
  3. Click on 'Add' button to get Update Center Customizer popup
  4. Set name to 'Beta 1'
  5. Set URL: to ''
  6. Press 'OK'
  7. Click to 'Available Plugins'
  8. Click 'Reload Catalog'
  9. Choose 'Ruby and Rails'
  10. Pat yourself on the back
It appears that adding the first beta's stable catalog does not confuse the 2nd beta's list. With any luck we will have a community release which is easier to install by the time NetBeans reaches 7.0 final.

Thursday, February 17, 2011

Ruby on NetBeans lives!

The NetBeans team reported that they were dropping Ruby support in their IDE. They also said they were hoping that someone in the community could pick up support. Over the last couple of weeks I have been talking to the NetBeans team about how the community can take over support. I have also been trying to educate myself a bit more in what it would mean to support Ruby in NetBeans. The short of it is: Ruby NetBeans will continue to live and hopefully thrive via community support.

The rest of this entry will explain why Ruby on Netbeans is important and how the community can support this effort. Hopefully, by the time you are done reading this, you will want to help out!

Why is NetBeans Ruby support important?

The truth is virtually every Java programmer on the planet is using one of a small handful of IDEs. The big ones are NetBeans, Eclipse, and Intellij. When a Java programmer decides to look at new language one of the first questions they ask is: Is there an IDE for it? Or...Does that run on NetBeans? JRuby (and Ruby) has quite a bit of motivation for Ruby support in Java IDEs because we see it as one less hurdle for a Java programmer who wants to try out Ruby.

This last paragraph may explain part of the motivation from the perspective of a Ruby evangelist... but it says nothing about the usefulness of Ruby on NetBeans. The editor is great. It has many conveniences like snippets, context sensitive navigation, live debugging, Rails support (2.x), and so much more. As a tool, it would be a great loss for all this work to disappear. As a programmer who spends most of his day in NetBeans, losing Ruby support would be a tragic loss.

A plea for contributors

I work on JRuby full-time. For me, hacking on NetBeans will be an OSS project where I contribute during my spare time. Several other JRuby folks will also volunteer some time under the same conditions: Yoko Harada, Charles Nutter, and Nick Sieger. Don’t be fooled do not have to be a JRuby hacker to work on this fact in the not-so-distant future you might not even need to to know any Java (more on this later).

Another treasure trove of expertise will come from Erno Mononen. Erno was one of the Ruby NetBeans engineers until his departure from Oracle. He makes no promises in how much time he can provide since he will also be contributing in his free time, but he should be an invaluable resource. Even if we only get to occasionally ask him questions.

Also Geertjan Wielenga, who has been helping answering questions about undertaking this community support and also pointing me towards NetBeans training resources has also offered his help.

So we have a few people who are offering to help make this a reality, but we can use all the help we can get. If you are interested in helping you should join the dev mailing list dev AT (instructions on how to access mailing: Introduce yourself and your interests in helping out.


We are going to continue to leverage as much of NetBeans infrastructure as we can. I mentioned continuing to use their mailing lists. We can continue to use their issue tracker. The hg repo will still remain the normative source for what gets released. However, in an attempt to make things easier to develop, we plan on mirroring the hg repo on Rubyists are huge git fans. Adding a git repository will lend a lot more visibility to the project. The git mirror has not been set up yet because we haven’t figured out how much of NetBeans should be mirrored.

By staying on NetBeans infrastructure it will be an easier path to get free continuous integration support on and it will also make it simpler to integrate into NetBeans AutoUpdate process.

Stay tuned for announcements about the upcoming github mirror. At the same time we announce the mirror we should have a simplified document on how to build Ruby NetBeans.

First steps

0. Simplify the Build process so it is trivial to get started

Let's face it...cloning 1.2Gb to compile a module is a barrier to entry. It is possible to compile without cloning all of NB source, but specifying the 10+ Ruby-related projects you need to clone is a little confusing (to me at least :) ).

1. Restart continuous integration testing on

2. Mirror hg source on

This will be easy once we nail down simplifying the build process.

3. Unbundle JRuby source

Currently, a full version of JRuby’s source gets checked into the repository and then it gets patched. The delta of things patched is very small and we should be able to eliminate the need for patching.

We will still depend on JRuby as a jar (see next step).

4. Use JRuby embedding support to write portions of Ruby NetBeans in the Ruby language

All people interested in Ruby NetBeans support already know Ruby. Not all of them know Java. Having strategic portions written in Ruby will help improve the amount of contributions we get.

We shouldn’t go hog wild about replacing things which work already, but this is a good opportunity to implement new things in a way which will allow Ruby hackers to contribute to Ruby NB.

5. Re-prioritize issues and get volunteers to work on them

There are currently 600 open issues. Many of these will need to be re-prioritized based on the level of support we can provide.

Here are the some of the important ones:
  1. Rails 3 support (only Rails 2.3 current supported)
  2. Bundler support
  3. 1.9 syntax
  4. Crashers
Personally, I plan on hacking on 1.9 syntax first since I have the most experience with this task and Ruby 1.9 is becoming too important to not support it.

People can come on the dev mailing list and talk about what they want to work on.


Ruby on NetBeans is already an impressive project, but like any OSS project it needs maintenance and care. If you think Ruby on NetBeans is important and you’re thinking about helping...please do. Even if you know nothing about NetBeans internals or you have never contributed to an OSS project before: Jump in head first! Getting involved in OSS is always a great learning experience and you will be a better person for it.

Tuesday, March 16, 2010

Limelight Notes: Styling

Basic notes I am gathering on Limelight GUI framework. These are just notes that are useful to me for the research I am doing. I am throwing them up on my blog because others may find this useful as well....This is also an experiment in using MacJournal as a new note taking tool.

Prop Layout

You can layout props based on fixed size (e.g. 30 in pixel) or on a relative size ( ’90%’ of parent). If the current prop will run past 100% width then it puts that props on a new row and a y position with is one more than the tallest prop in the preview row. Two examples...

This shows that the orange and green box are laid out at a y of the tallest previous prop (blue):

root :width => 500, :height => 500 do
box :width => '50%', :height => '10%', :background_color => :red
box :width => '50%', :height => '50%', :background_color => :blue
box :width => '50%', :height => '50%', :background_color => :orange
box :width => '50%', :height => '50%', :background_color => :green


If we modify this example a little bit:

root :width => 500, :height => 500 do
box :width => '50%', :height => '10%', :background_color => :red
box :width => '51%', :height => '50%', :background_color => :blue
box :width => '50%', :height => '50%', :background_color => :orange
box :width => '50%', :height => '50%', :background_color => :green


We can see that the red and blue box are laid out on separate rows now since the width of the blue box would have exceeded 100% if it was put onto the first row. This example shows another important aspect of layout. prop layout is first come first serve. The first two props fully fit the requested width and height, but the second two seem to run off the bottom.

Style Resolution

Style resolution most important to least: inline, prop name, left to right styles attribute values in that order.


box :width => 100, :height => 100, :styles => "big_box, heh", :background_color => :blue, :border_width => 5, :border_color => :black

box {
border_color :red

big_box {
border_color :orange

heh {
border_color :blue

With all three, then we notice that the color is black. If I remove the inline element then we see that ‘box’ one. And ‘big_box’ comes in third if we comment out box. ‘heh’ comes in last.

A second aspect to style resolution is that any style which has overlapping behavior ends up wiping out the other style. So for example, if in the example above I add ‘left_border_width 1’, then the inline styling wipes this out with ‘:border_width => 5’. If we swap these two values so that left_border_width is the inline style then we will just see the left border and the border_width value will be wiped out. This is a very simple rule, but perhaps not what is expected in cases because

Styles in Limelight have no inheritance unlike CSS. Setting border_width of 1 on a parent will not cascade that rule to its children. If you really want to share behavior you can use extends:

fill_parent {
width '100%'
height '100%'

box {
extends :fill_parent
background_color :orange

I find this to be pretty powerful, but I would like to find a way to add methods which allow me to reduce text:

def percent_dims(w, h)
width w.to_s + ‘%’
height h.to_s + ‘%’

fill_parent {
percent_dims 100, 100

I know there is a way to extend style system, so I need to look into that...