Archive for category Uncategorized

Fixing xclip

Xclip could be a great commandline tool for pulling things into your clipboard. I say ‘could be’ because remember the options needed to use it is as bad as using tar. I was digging around for a solution, and found a great bash script at madebynathan that solves the problem.

The madebynathan site suggests adding the script to your ~/.bashrc file. I like to keep my bashrc a bit cleaner, so instead I saved the script as ~/.cp.bashrc so that I can easily remember what chunk of code causes ‘cp’ to work.


  • Pipe anything to the clipboard
$ tail -n 100 /var/log/apache2/error.log | cb
# => Copied to clipboard: [Sun Oct 02 08:02:08 2011] [notice] Apache/2.2.17 (Ubuntu) configured -- resumin...
  • Copy the contents of a file to the clipboard
$ cbf ~/.ssh/
# => Copied to clipboard: ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAnwaNIuOhZzUeR6/xEEudXt3zEh91dawhkkKx8p/+4Bw9...
  • Type straight into the clipboard
$ cb This is some unquoted text.
# => Copied to clipboard: This is some unquoted text.

No options, no man pages.

Installing it

If you think this looks handy, add the line

source ~/.cp.bashrc

to your ~/.basrc file. Then save the below code section to ~/.cp.bashrc, and rock the easy xclip magic

# A shortcut function that simplifies usage of xclip.
# - Accepts input from either stdin (pipe), or params.
# ------------------------------------------------
cb() {
  local _scs_col="\e[0;32m"; local _wrn_col='\e[1;31m'; local _trn_col='\e[0;33m'
  # Check that xclip is installed.
  if ! type xclip > /dev/null 2>&1; then
    echo -e "$_wrn_col""You must have the 'xclip' program installed.\e[0m"
  # Check user is not root (root doesn't have access to user xorg server)
  elif [[ "$USER" == "root" ]]; then
    echo -e "$_wrn_col""Must be regular user (not root) to copy a file to the clipboard.\e[0m"
    # If no tty, data should be available on stdin
    if ! [[ "$( tty )" == /dev/* ]]; then
      input="$(< /dev/stdin)"
    # Else, fetch input from params
    if [ -z "$input" ]; then  # If no input, print usage message.
      echo "Copies a string to the clipboard."
      echo "Usage: cb <string>"
      echo "       echo <string> | cb"
      # Copy input to clipboard
      echo -n "$input" | xclip -selection c
      # Truncate text for status
      if [ ${#input} -gt 80 ]; then input="$(echo $input | cut -c1-80)$_trn_col...\e[0m"; fi
      # Print status.
      echo -e "$_scs_col""Copied to clipboard:\e[0m $input"
# Aliases / functions leveraging the cb() function
# ------------------------------------------------
# Copy contents of a file
function cbf() { cat "$1" | cb; }  
# Copy SSH public key
alias cbssh="cbf ~/.ssh/"  
# Copy current working directory
alias cbwd="pwd | cb"  
# Copy most recent command in bash history
alias cbhs="cat $HISTFILE | tail -n 1 | cb"  

Sprint Planning, now with disposable side-tasks!

TL;DR: When planning sprints, don’t pack your ‘nice to have’ features in the end. Pack 20% of each sprint with ‘Nice to Have’ or ‘candy’ features, so you can throw them away.

Planning sprints is a mixture of an art and a science. It’s hard to get all of the features you need (and some of the ones you want) stuffed into a development cycle. One of the tools I use to keep a project on track is making sure I have sacrifical features (or tasks) in every sprint, usually accounting for about 20% of the spint goals.

Lets say you have a project of 12 sprints, and 20 ‘dev points’ per sprint. A pretty normal breakdown would be to have some core features(red, 60%) and some should-have features (yellow, 25%) and a some nice-to-have features (green 10%). Oh and a little candy (blue 2%) as well as some tools (purple 3%) to build. I know this is a bit of a simplification, but I think if you know sofware, you get the gist. So go with it for a min.

Naive Sprint Packing

Now, your newbie SCRUM master will try to plan out a set of sprints for success. Naturally, she wants to get ‘Core’ done, then tinker on nice-to haves. So she plans the project as:

Looks nice right? Get hard stuff done first! If that seems like a plan for success, you probably haven’t run many sprints. To begin with, you can’t build all core fetures in a block. Any time you have interoperation, you have two choices: Define everything up-front (and fail) or make a basic design and evolve (and fail less). See Also ‘Waterfall Model Considered harmful. Core features are not as parallizable as ‘side’ features.

So, that red block of project will creep, or get delayed, just by the nature of development. Once that happens, each update to managment, and time you check your timeline, it will end with ‘and we are behind on Must-Have A,B, and C’. Every. Update. For weeks. As a hacker, you may know that is not bad, and it’s just lag from the front end, but to management and to your not-as-logical-as-logical parts of your brain, what they hear is ‘FAILSAUCE’.

Intermediate Sprint Packing

A more experenee scrum master will break things out a little more, and do something like this:

Again, it’s getting better. Now when things drift, they are more likely to be yellow items, so it’s not such a failure, and you can cast those off. But still, I bet 3 months pay that 99% of projects (yours) will be behind by sprint 8. Instead of red, Yellow items are failing, but still, there is fail.

Advanced Sprint Packing

A more experience scrum master is going to spread things out even more, and make sure, every step of the way, there are tasks that can ‘fall off’ a sprint, without killing the final deliverable.

Every sprint will go bad. Unless you are both awesome and amazingly lucky, almost every spint some core-task will go over estimate. Those red tasks are going to be on the plate almost every sprint. And every sprint you will have some Blue/Green tasks to throw away. Why? Because your estimates will be wrong, mistakes will happen, and you want to throw some luggage overboard, and make the product skinnier, instead of having late items the whole project long.

When you pack your ship, keep some extra luggage around to throw overboard during the journey!

from sanctimonious limb

Adam was my grandfather,
a tall spoiled child,
A red clay tower,
in Eden green and mild,

He ripped the sinful poppin
from sanctimonious limb
Adam was my grandfather,
i take after him.

– Unknown (to me)

A kid!

I wrote this post about 6 times. A funny one. A science-y one. A funny sciency one. A sciency-funny one. A serious-funny one. Even a sciency-serious-snarky ones. But honestly, it was all for naught. all of those were lame attempts to match Steph’s fantastic announcement post. <- Read it and weep, for it is intelligent and full of lulz. Too lazy to click? SPOILERS BELOW:

Steph and I are having a kid! It’s due to arrive around Mid-August.

That's no moon! It's a battle station tiny human!

Steph has done 90% of the work so far. But within weeks, the two of us will have a mewling, needy breast-milk-powered learning machine. I’ll need to step up, take some time off of work, and start the long-investment game of getting another human up to speed on what this planet is all about.

By all accounts it will be awesome and terrifying. It’s wily use of attachment behavior will forever alter my brain and chemical balance, and drive me to love it madly, and defend it fiercely. Even despite some worries about my fitness to parent, I look forward to helping this little human get their life together, and get them setup to do and be something worthwhile in their own life. That is, if I don’t do something stupid and get killed and/or detained by our new Police State first.

Here’s to genetic mutation and selection! Here’s to being a mammal! Here’s to baby-not-yet-appearing-in-this-film Alarcon!

It’s not going to be easy, but it will be worth it.

Radical Constructionist

I occasionally designate myself as a Radical Constructionist when I talk about technology, the world, and my outlook. A bit different from Radical Constructivism, I sometimes can be goaded into a rant when the topic comes up. So here, in short, is a shot at what I mean.

Humans exist as a species based on two skills, as best I can tell. Our ability to work as a team, and our ability to build tools. We are small, pink, tasks omnivores. Unlike racooms, or dogs, we don’t evne really have sharp bits. To make up for that, we hard to learn to get smart, collaborate, and make tools.

And one of the most amazing things about our tools, is how they shape us. As a species, once we have developed a tool, it shapes us. From the paper-based ideas of the US Constitution, to the suburban obesity of 21st century Americana, once our tools are in circulation, they shape what we do. Due to neotony and neural plasticity, I believe we are shaped ever more and more by our tools. Humans continue to learn later and later in life, and it’s more and more necessary to reshape and learn as we grow older. Our tools become a selection mechanism in an every weirder, less understandable cycle of human evolution as a species.

We actively reshape humanity, through selection of our technologies, tools, and ideas. I believe that by making tools that work better, tools that reflect a growing a sane order in the universe, we can make things that are not only fun to use, beautiful to behold, but these tools can move our very species forward and upwards. I also think that any humans should have access to all of the knowledge and tools they need to improve their own state of things.

Is this the future?

There are amazing moments any sci-fi geek has when they realize they are living in the future. As I tab through some Friday night browsing, I have a How to protect your data from the government article in one tab, an article about anarchists contribution to the Occupy movement in another.

I watch a video of House Speaker Baner censor news broadcasting of on the floor debate in our House of Representitives, and on the other hand a homophobic mayor is outed as gay due through expenses transparency.

So i turn off my browser, and get back to printing christmas gifts on my MakerBot. Man, the 21st century is weird.

Bug Labs: Open Source Head to Head

created on: 05/01/11As part of research and development (aka R&D to those in the industry) I ordered an Ultimate Beagle Gadget Pack from our friends over at Liquidware.  As one of the new wave of Bug-gneers that joined this winter/spring, I want to get a good understanding of our friends and competitors in the embedded Linux world.  Of course, as an open source company many of our friends our our competitors, which is really cool. It’s Especially cool when you can inspire new ideas across company, team, and international borders.

I’d rant about ‘marginal cost of software’, Syndicalism, and Eben Moglen here but I better not.  I think  folks are here for the hardware, not for the hobby armchair economic and philosophy. People are here for open source development,  for quality hardware/software platform, and for the creative new ideas Bug dreams up.

In the spirit of the second, this is the opening post of ‘Open Source Head to Head’ series.  It will be a sporatic series, coming ont when I have time and a new toy, where I’ll be comparing Bug Labs products with those of our friends, competitors, and collaborators.  This will include projects and products we use in development, competing products, and contrasting approaches to design.

I’m calling these ‘Head to Head’ because both meanings of that apply to Open Source development.  As a solutions company we are competing on an open market.  We aim to have the best ideas, and to make the best platform for  our customers to build on top of.  However at the exact same time, we are constantly sharing ideas with the entire world at the speed of our own innovation. And we, in return, and getting great ideas shared back as quickly as we put them out. I think that is a powerful combination of incentives, and a fantatic model for driving innovation for our company, and for the whole human race.

It almost goes without saying that I’m going to give the fairest assessment I can. Not only because it’s the right thing to do, but because as developers and engineers we learn from our mistakes and shortcomings. Being honest and clear about that is good for science, and good for customers.  But  of course as a Bug-gineer, I’m may be a little tiny bit bias’d (Bug Rules!) in my review despite my best effort to be neural.

(Image courtesy of DoubleM2 on Fickr, licensed as CC BY 2.0. Thx DoubleM2!)
(This post is also  cross-posted at )

Tags: , , , ,

New Gig!

I spent the last few months of my life dipping into my own saving, and trying to work with a friend to create a scientific device via our own small engineering company around. Unfortunately, my pockets are not as deep as I had hoped, and the problem more complex that I planned for.

My first plan was to try contracting work for a while. However while digging around, I stumbled upon an opening for a Linux Embedded developer position that seemed pretty nifty. So, I applied for the position, and got the position. So after clearing my calendar of current obligations, I’m starting work at MEI shortly.

The job looks pretty keen, and from what I’ve meet of the engineering/software team, it’s a good crew of people to work with. The only non-trivial downside is the reverse commute (which is longer than I like for). So, it’s back to working-stiff hood for me! Writing Linux drivers and apps isn’t going to be very stiff-ly though.

Tags: , , , ,

arm-elf-gcc of doom

I am stick in the position of reinstalling arm-elf-gcc again, for the 3rd time. The second time I simply copied the arm-elf directories from my old system to my new, so maybe this only counts as the second. My new install is x64 (running on a MacBook Pro 5,1) and it had problems trying to run the old version.

I had two approaches in mind when I started working on this. One being
simply to follow the generic Making Things instructions, the second to download and build the toolchain based on nutaksas.

I tried grabbing from nutaksas first. The script ran OK, and downloaded and built everything I needed. However, when I tried my o
ld make files, I ran into a problem with duplicate symbols. (Unfortunately, I can’t recreate it, as I already fixed/replaced the problem). Since the colission was in libc.a, the next thing I tried was rebuilding with –with-newlib disabled. It was a longshot (and didn’t work), instead of problems linking, I got compile errors for “printf(“.

After which I fell back on ye olde download the prebuild libs trick. Instead of adding /usr/local/bin/gnuarm-3.4.3/ to the path, I made softlinks using “sudo ln -s /usr/local/gnuarm-3.4.3/bin/arm-elf-* /usr/bin.”

26C3 Highlights