Some Bits on Binary Packing and Holding Broken Packages

The first part of my day was spent on binary packing in Python. When using this feature to share objects between languages, you pack the structure/object into binary and deliver it with instructions for how to parse or unpack it. The format of the instructions will look something resembling this:

self.fields = "5i41sxxx"

where the structure is comprised of 5 integers followed by a 41 bit string followed by 3 null bits added for padding to make the structure add up to a total of 64 bits. My current task on the OHM was to add the {t} variable to this binary structure. Misunderstanding, I added the length of the 5 bit string to the existing 41 bit string. However, I learned that, unlike for the 5 integers, 46s would be treated as a single 46-bit string (logical but not obvious to me at the time). Instead, we opted to insert a second 5-bit string before the padding (which was increased to a total of 61 to increase the size of the binary structure to a nice, even 128 bits.)

Later that day, I spent a lot of time searching for solutions to an installation problem I was having. My updater was howling about need to update the firmware. My initial attempts were met with a strange error about having "help broken packages" (which drew up a most disturbing mental image). After lots of searching, I finally found a helpful post on AskUbuntu which described in detail the steps needed to clear this error. After typing:

sudo apt-get install xserver-xorg-lts-precise
hwe-support-status --verbose 
sudo apt-get install linux-generic-lts-trusty \
xserver-xorg-lts-trusty libgl1-mesa-glx-lts-trusty \ 
linux-image-generic-lts-trusty

TBH, though, I kind of wish that I hadn't updated because now Spotify won't run in my browser and the delete key fails on a long press. Google's suggested search when searching straight out of the address bar is malfunctioning as well. Something good will come of it, though. I'll have some fresh learning to write about tomorrow night!

10 Ways to be Smarter

A recent article by Jessica Stillman in Inc. magazine summarizes a recent Quora posting on what can you can do to get smarter. In short:

1.  Be smarter about how you use your time on the Internet. Think more TED talks, Khan Academy and (presumably, Inc. magazine) and much less YouTube, Farmville and Cracked.com.

2.  Write 400 words a day about something you learned that day.

3.  Make an "I did it" list to remind yourself of your accomplishments.

4.  Play games: chess, Connect 4, bridge, (MtG, anyone?).

5.  Surround yourself with friends who are smarter than you.

6.  Read a lot. A lot.

7.  Explain what you've learned. You don't really know it until you can teach it to someone else so they will understand.

8.  Do random new things. You never know how what you learn will help you down the line.

9.  Learn a new language. (I hope programming languages count!)

10.  Take some time to digest what you've learned. Sit and think (or exercise and think.) Spend time thinking.

I'm going to start with #2 tonight.

How to Change Tab Size in Vim and Other Nifty *Nix Tricks

I learned two nifty *nix tricks this week that I'd like to save here both so I can find them again if I manage to lose my notes (or my muscle memory) and in the hopes that I can save another future dev a little bit of time.

To change your tab size in Vim, first at the command line, type:

vim $HOME/.vimrc

This will open the user preferences file for Vim, creating it if the files doesn't already exist. You will then be popped into your Vim editor, where you can enter your preferences. Remember to type the letter a to enter insert mode. Otherwise, anything you type will be interpreted as a Vim command. Ready?

Here's where you can paste all those nifty "yak-shaving" "time-saving" snippets you've been finding online! I used

set tabstop=4
set shiftwidth=4
set expandtab

Press the esc key to re-enter command mode then :wq to save and exit. Re-open Vim and voila! You've just set your tabs to 4 spaces!


My second trick is much shorter, but it's a great little command just the same. When working in Git, before you add any files using git add type

git diff

to see the changes you've made across all of the files in your working repository. If you've already started tracking the files using git add, type

git diff --cached

It gives you lovely output such as:

That's all for now. Happy coding, everyone!

Progress and More to Come

We made some progress over the last two weeks. We've got the time query running through the software, all the way up to the point requesting the tiles. Now we're diving in to the code of the renderer and tile server to get those tiles that we need!

Week 9: July 14 - July 20[edit | edit source]

1. After some discussion and direction from my mentor, I'm tackling the tile rendering server bit. I've added a test layer for "Year" in the leaflet.osm.js file.
2. I've got a first little skeleton in the code but it doesn't lead anywhere yet. I updated the issue tracker in GitHub with my latest and (not so) greatest.
   1. The screenshot is also posted here
   2. As can be seen by the mostly empty layer on the right, I've got most of the plumbing in there but there's no data coming through the pipes.
3. Digging further into Leaflet and how to use it and I also put up a white flag for assistance in the issue thread above

Week 10: July 21 - July 26[edit | edit source]

1. At the beginning of the week, I felt a little discouraged after seeing this postin the mailing list about how nomoregrapes built a working slider over an isolated OHM map during the Hackathon at SoTM-EU. I went through thecode he posted on GitHub and linked to it in the GitHub OHM issues tracker.
2. After a lot of hacking and many false starts (and some help from my mentor), by the end of the week, I found the proper places in the code to add references to the {t} value for searching. My commits and code.

In less positive (and more personal) news, I got word that I was not accepted for the next cohort of the Ada Developers Academy. Keep looking here because after my OPW internship is over, I'll post my progress on my work for the GitHub data challenge!

In the Weeds

I've been spending the last few days in the weeds of Leaflet. For the full play-by-play, you can see the GitHub issue.

My Very Frustrating Day

Fastest Summer of My Life!

Time seems to be moving faster and faster. I can hardly believe it's time for another two-week report! I spent a lot of time chasing bugs but I'm making baby steps forward and learning a lot about how Rails and JavaScript work in live code.

Week 7: June 29 - July 5

• On Monday, the OHM team had our monthly Google Hangout (which I have learned is the first Tuesday of the month). The very sketchy notes are posted online.
• At the Hangout, I was introduced to a new resource: the design prototypes for Wikimaps search. I'm pouring over them today. In fact, I spent an inordinate amount of time reading new material and going through archives to catch up. At every Hangout or meeting, I come across more terms and talking points that leave me confused. I'm filling in the gaps. My reading list has included:
• reports on Zurich Hackathon
• the Wikimaps Search Design page above
• more on vector rendering of tiles in preparation for my next steps
• RfC for How to Deal with Open Datasets
• Overview of Wikimaps
• I am getting most anxious about continuing to work on my own branch of the OHM for so long. I would like to push to Master soon, but I need a better-working demo before I do so.
• I've been spending a lot of time there attempting to craft an appropriate request to get something other than a doctored error message to appear on the site when searching by year.
• The most excellent Frances Hocutt introduced me to the Wikidata API Sandbox. It is proving quite helpful. APIs are a whole new world to me.
• To appease my anxiety, I submitted a pull request with my most up-to-date code. 

Week 8: July 6 - July 13

• And the code I've written was deemed not yet ready for prime time - it only works halfway at this point. I will resubmit after I get the code up to production standard.
• After some useful feedback on the importance of submitting a pull request with only one commit (and some pointers to how-to's on rebasing to make that happen) and the helpfulness of of including *lots* of screenshots showing the software in action, I closed the pull request.
• One (!!) of the aspects of this project that I have found especially challenging is finding my way through the blending of JavaScript and Rails code. I spent an inordinate amount of time this week chasing down what turned out to be a Javascript syntax error that was manifesting as a Rails error.
• I've installed the "better_errors" gem to try to assist with errors like this - it will presumably be triggered if it is a true Rails error
• I've also learned that if I make changes to the JavaScript portions of the code, I have to restart the server in order to see any changes. Most changes to the Ruby code automagically propagates without restarting the server.
• Screenshots of my progress so far are on GitHub. Searching by year (2008 and 2009) will bring up the Burning Man map layers for those years and recenter the map to that area. Searching by any other year brings up with message that this is a work in progress. (It no longer crashes the map and brings up the dreaded Rails error screen, so there's some progress there!)

Hoping to Catch My Breath

I've been so immersed in my internship that I've been neglecting this poor blog. I'm still constantly surprised at how much longer seemingly simple tasks take. I'm very slowly getting familiar with the complexity of the OHM codebase. Here's a rundown of the last two weeks:

Week 5: June 16 - June 22

• I spent far too long this week chasing Heroku errors in an attempt to get a live version of my time_slider2 branch online. After an IRC chat with my mentor, I cut my losses and moved on to the next task:
• Capturing the start_year value entered from the TimeSlider
• I found a new resource: a StackOverflow-style QA page for OSM
• Regrettably, this resource seems focused on map-editing users. It did help me discover when I was headed (meandering?) down the wrong track with the router file in Rails and needed to pivot and work on the router.js file.
• This was a real Edison week. I found a dozen different ways that don't work. Still at it.

Week 6: June 23 - June 29

• Completed and submitted my mid-session evaluation.
• I'm not where I thought I would be at this point in the session. There is a tremendous difference between the code used in tutorials and student-level projects and the real, live code that lives out in the wild.
• It's more than just the complexity (although the huge leap in complexity would be more than enough to stymie me!) There are unfamiliar conventions and blending of platforms that still surprise me. (I'm still getting caught flat-footed and discovering that the code I'm writing in Rails needs to be ripped out and put into the JavaScript portions of the code base.) I will learn.
• I'm having a meeting with my mentor on Tuesday, and hopefully that will give me some grounding.
• I'm making an effort to commit more often and to push up my commits to my branch more regularly. I've been fearful about doing so but last week, I caught myself trying the same failed function twice. Having all of my commits with failures noted well help stop me from doing that in the future.
• I made some baby steps toward success:
• screenshot
• issue tracker