Much ado about scripting, Linux & Eclipse: card subject to change


Cast media from Windows netbook to Android tv box

Finally figured out a simple way to cast media from my netbook to my TV box. 

On the Android box:

1. Install AirPlay/DLNA Receiver (LITE or PRO) from https://play.google.com/store/apps/details?id=com.waxrain.airplayer&hl=en

2. Launch the app. Turn on DLNA DMR then set a device nickname. Apparently also works with AirPlay and AirTunes if you want to stream from an iPad/iPhone. 

On the Windows box:

1. Enable media sharing in Windows 10 from Control Panel\Network and Internet\Network and Sharing Center\Media streaming options (requires admin access).

2. Install http://download.waxrain.com/AirPinPcSender/AirPinPcSetup.exe to send media from Windows to receiver.

3. Browse for media file on Windows machine; right-click and select Cast To Device or DLNA Play to > [your android device].

That's it!


Jelly Bean Keyboard - Cursor Keys

Ever wanted to add cursor movement keys to your text messaging experience? The Jelly Bean Keyboard includes this option, but it's somewhat hidden. Here's how to find and enable it.

First, download the app from the Google Play Store: https://play.google.com/store/apps/details?id=com.jlsoft.inputmethod.latin.jbk43.free&hl=en

Next, go into the settings applet, then find "Languages and input".

Now look for Jelly Bean Keyboard 4.3 you installed earlier from the Play Store, and tap the gear icon next to that to enter settings for the keyboard.

Here's the confusing / hidden setting part. Across the top, there's a "Standard Settings" bar, and under that is stuff like Auto-capitalization, Vibrate on keypress, Sound on keypress.

To the RIGHT of "Standard Settings" is a "JBK 4.3 settings" item, which you can access by swiping from the right to the left.

Now scroll down until you see "Key layouts". Below that are options for keyboard layouts when you're in landscape or portrait orientation. Next is an option for "Show arrows" which you can set to Never, Portrait, Landscape, or Both.

The result? This:


New Year's Day

Been too long since I blogged here. Time to begin again.
All is white on New Year's Day
Like a dead channel, on the TV
I want to be coding
Be coding night and day
The more things change
The more they stay the same

I will iterate again
I will iterate again

Under a neon bulb
Group of devs chatter, in @s and pings
Bugzillas logged, JIRAs are too
The blogosphere says, says 
Say it's true, it's true...
And we can break through
Though platforms too 
Many spring from one 

I... I will write some tests again
I... I will write some tests again

Maybe the time is right
Oh... maybe tonight...

I'll debug my tests again
I'll debug my tests again

And so we're told it's the container age
Transform and deliver your apps a new way
Still I want to be coding
Be coding night and day
The more things change
The more they stay the same


A Day In The Life

Can't believe it's been a full two years since I last posted to this blog. Time flies when you're making change.

I read the blogs today oh boy
About more JS frameworks on their way
And though the news was rather sad
Well I just had to laugh
I saw the infograph

It was yet another approach
To solving the same things of yesterday
A crowd of people stood and trolled
They'd seen this stuff before
Nobody was really sure
If it was like IO or Node

I saw a tweet today oh boy
Toronto street car service is still slow
They've crowds of people every day
But I still have to drive
Cuz of where I live
I'd love more subways here

Woke up, fell outta bed
A Beatles earworm in my head
Found my way down th'hall and dialed my call
And sitting there I noticed sound was dead

Found my phone in seconds flat
Bluejeans worked, so that was that
Found my way online (had to reboot)
And somebody spoke and I went into a dream

I read the logs today oh boy
Thousands of commits by hundreds of folks
Though some issues were rather small
We had to count them all
Now we know how many tweaks it takes to make a new release
And how to turn it on


The JBoss Developers' Song

Hey! Guess what?

JBoss Tools 4.0 and JBoss Developer Studio 6.0 are available today. So... a quick tune in tribute to all the hard-working people who made it happen.

Who squashes bugs users have found?
Who keeps the unresolved count down?
We do! We do!

Who answers to the Will of Max?

Who deals with all of the PEBCAKs?

We do! We do!

Who closed/resolved a thousand bugs?

Who attends all of those JBUGs?

We do! We do!

Who fills more roles than Tom Hanks?

Who gets the top Marketplace ranks? 1

We do! We do!

1 - As of 2012/12/07, JBoss Tools + JBoss Developer Studio successful Eclipse Marketplace installs for Helios, Indigo, and Juno total over 141,000. SpringIDE and Spring Tool Suite installs total over 163,000. This puts us #5 behind only Maven, Subclipse, Subversive, and Spring.


Open Source is Painless (Theme from JBDS)

With JBDS 5.0.0.CR1 and JBoss Tools 3.3.0.CR1 out, and GA/Final releases just around the corner, it's high time for a new song.

Hell's bells, it's been over 3 years since my last music-related post.

The idea for doing this song came after spending a day creating a diagram showing how JBoss Tools and Developer Studio are built, followed by myarboro's reaction to the complexity.

Diagram by Dia

Through early morning mail I see
Visions of JIRAs for me
Build jobs red unexpectedly
I realize and I can see...

That Open Source is painless
Even with non-stop changes
And yet we give all this away for free

The game of rel-eng's hard to play
We struggle through it anyway
A business card I'll never lay
Deprecated: it's LinkedIn's day

Jenkins builds are painless
They track so many changes
And ever onward moves complexity

The use of Git trumps SVN
But migrating's hard to begin
When your code base is not so slim
The pain grows stronger... bear & grin

Using github's painless
Pull/push requests for changes
And I can take or leave it if I please

A Turing test once asked of me
To answer questions that are key
'To use Tycho or PDE?'
And I replied 'Not PDE!'

Releng'ing is painless
It is a game of changes
And still we give all this away for free
And you can do the same thing if you please...

Johnny Mandel & Mike Altman - Suicide is Painless (Theme from M.A.S.H.)


Managing Jenkins job configurations

In JBoss Tools and Developer Studio, we manage a lot of build jobs in Jenkins. In fact, for the 3.2.x/4.x and 3.3.x/5.x streams, there are over 195 jobs. When we start building our next year's first milestone, we'll spawn another 40+ jobs.

Here are some of them:

To assist in performance, we use maven profiles in our parent pom to allow data to be shared outside the slaves' workspaces, without using shared workspaces (as that can lead to conflicts when multiple maven processes try to write to the same .m2 repo). Here's an example:

  <!-- same contents as jbosstools-nightly-staging-composite, but locally 
   available (to improve network lag) -->

We also use profiles to turn on code coverage analysis or to take advantage of Jenkins variables like BUILD_NUMBER when setting a timestamped qualifier for features & plugins:


But how do you deal with hundreds of jobs' config files, and how do you update them all easily w/o hours of in-browser clicking?

We maintain the job config files (config.xml) offline.

To do this, we use a maven plugin I wrote to fetch jobs matching a given view & regular expression and store them locally on disk using the same structure as on the server.

Then that same plugin can be used to push the config.xml files BACK to the server after making changes to one (or all) the files.

For an extra level of auditing, we also commit these locally cached config.xml files to SVN so we can track their history. Admittedly Jenkins provides this functionality natively, but when you're POSTing changes to config.xml files the server doesn't always notice a change and record the delta, so having a backup (particularly one you can diff offline) is never a bad idea.


Build Nomenclature Conventions: What's in a name?

The following post is inspired by Mickael Istria's recent blog, Call a spade a spade, and a Nightly a Snapshot.

When I was doing builds for the Eclipse Modeling Project, I-builds were weekly published nightlies -- same level of stability as a SNAPSHOT (to use Maven parlance) or nightly, but published on a weekly schedule to bridge the gap between nightly/daily/SNAPSHOT/CI builds and the every-6-weeks milestone releases. The goal was to provide something stable enough for early adopters to grab once a week, but without the non-stop flux of nightlies. Regardless of the label on the build, the process was the same: tag CVS, then build using that tag.

The Final/GA/Release ("R") builds were done as simple renames of the last good milestone or release candidate build, so as to ensure binary-compatibility w/ the last-tested milestone/RC. The same was true for "M" and "S" builds -- they were just renamed "I" builds, and the letter was there simply to differentiate between a maintenance build (M), a stable milestone (S), or release (R).

Branching only happened when a release was done and it was time to produce the maintenance stream vs. the ongoing next-year-release. Sometimes branching would happen AFTER the x.y.1 maintenance because it saved duplication of commits in the x.y+1.0 and x.y.1 streams.


Now at JBoss, we publish "nightly" builds, which are keyed to SVN changes and therefore could be as often as hourly or as infrequent as weekly, depending on what's happening in the repo.

We also do milestone builds about once ever 6-8 weeks (similar to the Eclipse.org release train schedules), which is more carefully vetted, tested, and QE'd. It is produced using the same *process* as the nightlies, but are named differently and pulled from a freshly-created stable branch in the repo (so its degree of change/churn is less). (Branching happens right before every milestone or release candidate so that hardening/stabilization/documentation can happen in the branch while trunk stays open for new development.)


Bottom line -- I've only ever needed three types of builds, regardless of nomenclature or labelling differences. And of these 3, the last 2 are the same thing but renamed to underline the build quality/stability:

* nightly/CI/integration/weekly/SNAPSHOT build (unstable, for bleeding edge adopters)

* development milestone (probably a re-christened nightly; stable, early adopters)

* stable release / Final / GA (probably a re-christened milestone; release quality)


So... does it matter if it's called nightly, integration or SNAPSHOT? or Stable, Milestone, Maintenance, Final, GA or Release? As long as it's easily reproducible (yeah, Tycho!), what's in a name?


HOWTO: Make KDE remember dual-monitor randr settings

Every time I boot up, KDE appears to forget that I want my monitors to be positioned left-to-right and instead defaults to mirrored config. But, after a lot of cursing and a little googling, I found an answer so it'll no so much keep your settings, but reset its broken config to your settings.

1. Hit ALT-F2, then enter "display" to run the Display Settings app.

2. Configure your settings as you'd like. Note that if the Apply button isn't active after your changes, you can change/revert something like a Position: button to make it active.

3. On restart, KDE may forget your dual-monitor settings. So, to prevent this, go look in your ~/.kde/share/config/krandrrc file:

StartupCommands=xrandr --output "DVI-I-1" --pos 1920x0 --mode 1920x1200 --refresh 59.9502\nxrandr --output "HDMI-1" --pos 0x130 --mode 1920x1080 --refresh 60\nxrandr --noprimary

4. Copy the configuration into a new file, and replace \n with newlines. I like to put scripts like this in /etc/X11 because they relate to screen res and positioning.

# from ~/.kde/share/config/krandrrc
xrandr --output "DVI-I-1" --pos 1920x0 --mode 1920x1200 --refresh 59.9502 
xrandr --output "HDMI-1" --pos 0x130 --mode 1920x1080 --refresh 60 
xrandr --noprimary

5. Ensure the script is readable/executable for all users:

chmod 755 /etc/X11/1920x2.sh

6. Hit ALT-F2, then enter "autostart" to run the Autostart config tool.

7. Click Add script... and browse for the script you created above.

8. Reboot and watch the magic unfold.


HOWTO: See what happened in SVN between builds

I was recently asked how to determine what changed between two builds. Jenkins provides nice interlinks into JIRA (issues), Fisheye (source changes), SVN (sources), but let's say you want to kick things a little more old school and investigate the old way... or the builds you want to compare are no longer shown in Jenkins because they expired and their metadata was automatically purged.

If you can't just look at the changelog in Jenkins to see what revision of source was used for the build, you can check the SVN log to find revision numbers based on the timestamp of the build.

So, if your build was generated on 2011-10-18, you can see that the log shows the last commit before that build was this:

$ svn log http://svn.jboss.org/repos/jbosstools/branches/jbosstools-3.2.x/


r35735 | bfitzpat | 2011-10-17 15:35:23 -0400 (Mon, 17 Oct 2011) | 2 lines
Changed paths:
   A esb/plugins/.project
   M esb/plugins/org.jboss.tools.esb.project.core/src/org/jboss/tools/esb/core/runtime/ESBRuntimeResolver_410.java

JBDS-1889 - Now checking for juddi-client-3.1.2.jar as well as 3.1.0 and 3.1.1 when seeing if the runtime includes ESB 4.10


Want to see actual diffs between that build and the latest one?

$ svn diff http://svn.jboss.org/repos/jbosstools/branches/jbosstools-3.2.x/@35735 http://svn.jboss.org/repos/jbosstools/branches/jbosstools-3.2.x/

Or, if you want to collect just the section of log relevant to the change:

$ svn log -r35735:HEAD http://svn.jboss.org/repos/jbosstools/branches/jbosstools-3.2.x/

Of course if you have all the sources locally, you don't need to log or diff via a URL - you can simply use local file paths. And if like me you use git-svn instead of pure svn, you can use that to diff or log too.

If you want to easily determine when a branch was created and get the SVN revision number for that branch point, use this:

# from r28571, returns -r28571:HEAD
rev=$(svn log --stop-on-copy \
  http://svn.jboss.org/repos/jbosstools/branches/jbosstools-3.2.x \
  | egrep "r[0-9]+" | tail -1 | sed -e "s#\(r[0-9]\+\).\+#-\1:HEAD#")

If you'd like to view a specific svn revision in your browser, use !svn/bc/REVISION_NUMBER/ before the branch and path to file or folder: