The learning curve was tremendous. Learning an older version of Rails, learning the monkeypatches on it, learning how to deal with metaprogramming from a refactoring perspective. Learning a new editor (SUblime, which I've grown to like quite a bit for dealing with really large files)
Learning about the team, and the team's customs (Jukebox for music was an interesting one...)
Environment issues, DNS server issues, lots and lots of Redis/resque issues.
Learning to take notes in a notebook rather than in evernote
Learning to take hipster jokes with grace and style- or at least without devolving into Godwin's law.
Reading innumerable books on the train.
Meetups- Ruby, Clojure, JavaScript, female developers (sorely needed), ChiSC (discontinued?)...
Setting up Bundler for a largish established app with custom local gems
Sunday, September 25, 2011
Tuesday, May 31, 2011
Project 1, rolled-off.
Friday was my last day on my first TW project. What have we learned?
Handover is very important, but with practice it can be done well with little effort. One centralized repository for knowledge is good, although in this case it's more like a combination of Mingle and direct email.
Turning a temporary build server off and back on again will teach you everything about how to set up new ones- also, where the script to do it is. Scripts are wonderful. I think that automating everything using Puppet would be even more wonderful.
Servers without enough space on them are an enormous nuisance when testing giant data import tasks. How to fix this: ask nicely. Also, back channels of communication.
Never assume that you know what an error message means (in Resque tasks, one task can fail because of a parsing error, without the rest of them failing. This happens when there is a small anomaly in the data. You don't need to fix the anomaly in order to finish running the test.)
Developers (well, me) are much happer when they get comfortable chairs, and floors with no holes for chairs to fall into.
git:// vs git@ is an important distinction: the first one gets a read-only copy, the second gets read-and-write. Your build server needs the first one, your development machine needs the second one. The second one throws interesting authentication errors against some firewalls. (I haven't figured out exactly what happened there yet.) When git clone fails and you're in a hurry, you can just scp over the most recent version from a different machine. This is deeply suboptimal because git pull will fail either consistently or sporadically, depending on your firewall configuration.
The db/data directory in a rails app is my favorite because you can auto-generate rake data import tasks by putting things in it.
RHEL (RedHat) 5.5 has no package for git. Use wget, configure, and make. Pick your favorite package version. http://kernel.org/pub/software/scm/git/
Always put your hardware diagrams and reference scripts in the repository.
If you have problems with unstable commits, label the obviously unstable and obviously stable ones. Git tag is a great command.
Making a diagram of iOS certificate signing is difficult, can be done in many different ways, and although ideally it would explain itself that is so far not the case; it's just a very useful visual aid to a question-answer session.
Mongo shell is a lot of fun.
Hotdogging someone's computer by making it easy to lock the screen is acceptable. On OSX, do this by:
System Preferences, desktop/Screensaver/, hot corners, put display to sleep (in one of them). Then, System Preferences, Security, Require password immediately after sleep or screensaver begins.
"Hotdogging" is a colloquial term for "doing something to an unlocked computer to point out to the owner of that computer that they shouldn't leave their computer unlocked"
If you have trouble hearing on the phone, there are several easy partial fixes:
Evernote will take over your life and become your primary external brain storage, but it will make you soooo on top of things. So it might be worth it. I would recommend using the opensource clone Nevernote instead; it has cooler features.
Pre-built secure RPMs exist (you'll probably want to make them yourself?) and you use them for your production machines. To prevent surprises, also use them in advanced testing.
Screenshots are beautiful, essential things when you are working in distributed teams. They reveal communication empty spots which you might have otherwise discovered at a less convenient time. Send them daily. Request them daily. They don't have to be fancy.
Rands in Repose wrote a very excellent book called Managing Humans and as a developer I enjoyed reading it; it discusses some very useful things about communication styles which were directly relevant to things I was having trouble with. (See above re: phone calls and distributed teams)
Handover is very important, but with practice it can be done well with little effort. One centralized repository for knowledge is good, although in this case it's more like a combination of Mingle and direct email.
Turning a temporary build server off and back on again will teach you everything about how to set up new ones- also, where the script to do it is. Scripts are wonderful. I think that automating everything using Puppet would be even more wonderful.
Servers without enough space on them are an enormous nuisance when testing giant data import tasks. How to fix this: ask nicely. Also, back channels of communication.
Never assume that you know what an error message means (in Resque tasks, one task can fail because of a parsing error, without the rest of them failing. This happens when there is a small anomaly in the data. You don't need to fix the anomaly in order to finish running the test.)
Developers (well, me) are much happer when they get comfortable chairs, and floors with no holes for chairs to fall into.
git:// vs git@ is an important distinction: the first one gets a read-only copy, the second gets read-and-write. Your build server needs the first one, your development machine needs the second one. The second one throws interesting authentication errors against some firewalls. (I haven't figured out exactly what happened there yet.) When git clone fails and you're in a hurry, you can just scp over the most recent version from a different machine. This is deeply suboptimal because git pull will fail either consistently or sporadically, depending on your firewall configuration.
The db/data directory in a rails app is my favorite because you can auto-generate rake data import tasks by putting things in it.
RHEL (RedHat) 5.5 has no package for git. Use wget, configure, and make. Pick your favorite package version. http://kernel.org/pub/software/scm/git/
Always put your hardware diagrams and reference scripts in the repository.
If you have problems with unstable commits, label the obviously unstable and obviously stable ones. Git tag is a great command.
Making a diagram of iOS certificate signing is difficult, can be done in many different ways, and although ideally it would explain itself that is so far not the case; it's just a very useful visual aid to a question-answer session.
Mongo shell is a lot of fun.
Hotdogging someone's computer by making it easy to lock the screen is acceptable. On OSX, do this by:
System Preferences, desktop/Screensaver/, hot corners, put display to sleep (in one of them). Then, System Preferences, Security, Require password immediately after sleep or screensaver begins.
"Hotdogging" is a colloquial term for "doing something to an unlocked computer to point out to the owner of that computer that they shouldn't leave their computer unlocked"
If you have trouble hearing on the phone, there are several easy partial fixes:
- use Skype (better sound quality)
- email the topics that you heard discussed to someone that was also on the call and ask them to fill in gaps
- get a hearing test
Evernote will take over your life and become your primary external brain storage, but it will make you soooo on top of things. So it might be worth it. I would recommend using the opensource clone Nevernote instead; it has cooler features.
Pre-built secure RPMs exist (you'll probably want to make them yourself?) and you use them for your production machines. To prevent surprises, also use them in advanced testing.
Screenshots are beautiful, essential things when you are working in distributed teams. They reveal communication empty spots which you might have otherwise discovered at a less convenient time. Send them daily. Request them daily. They don't have to be fancy.
Rands in Repose wrote a very excellent book called Managing Humans and as a developer I enjoyed reading it; it discusses some very useful things about communication styles which were directly relevant to things I was having trouble with. (See above re: phone calls and distributed teams)
Tuesday, April 19, 2011
"Why do I need to restart my iPad to install this app?"
I have no idea, but it's happened to me... development apps signed with correct UDIDs.
Sunday, April 3, 2011
What are you doing in there?
My first few weeks at ThoughtWorks have been interesting. When I first got back from India, I spent a weekend as a jetlagged zombie thanks to the 12.5 hours of time difference, but by Monday I was mostly functional and by Tuesday I was good to go.
My first Monday back in the USA I went in to the office, met up with my fellow Chicagoans from TWUXX, and had a series of chats with various people about our experiences and our future assignments. For a week, we mostly sat at the beach (a table where people not on assignment tend to sit... it has a palm tree ^.^) We spent some time looking at making a command-line interface for Mingle. It was all our own project, and we didn't make that much headway, although I learned a lot of interesting things about the structure of Ruby gems.
On the second week we worked on a small Rails app with some interesting algorithm problems- this was an assignment, not just a project that we happened to be working on. We were trying to refine the theory behind some not completely understood complexities in the algorithms. Around the middle of the week, I was taken off the project, so I didn't get to see the delivery of the first iteration... but I hear it was good!
I was now shadowing DevOps on a project in Chicago. I experienced conceptual overload several times in my first day there... not only did I learn about new tools, I learned about new concepts and new fields of thought. I enjoyed it very much.
I learned about the brother build systems Hudson and Jenkins and how they were different from Go/CruiseControl, and servers and server structure and I had my first introduction to CentOS, which is a clone of RedHat. I learned how Selenium, a web application testing system, can be run headless on servers. I began to increase my understanding of the structure and means of manipulating of firewalls.
I learned more about databases and mySQL, as well as becoming competent with ssh keys and server access. I learned which directories (on the servers for this particular project) were used for what. I gained an understanding of the complicated filetree of the repository containing the code that our servers were running. I learned what JIRA is (bug/request tracking software), and how useful they can be... and how many fields there are to fill out!!
After some time, I was given a new assignment, in a nearby location... as a DevOps person in my own right, setting up a simple build system. Now I'm learning to use Frank, which is similar to Selenium but for testing iOS applications.
Not only that, but in my copious spare time, I'm working with XNA 4.0 and I've been reading up on the OpenKinect library with an eye to doing something cool. In my personal spare time I've been trying to get my laptop to detect and understand the input from my SparkFun RFID kit, but it looks like I'll need to use Windows unless I discover something new.
Also I bought a new phone, a G2, and I'm enjoying learning my way around its interface and playing with apps.
My first Monday back in the USA I went in to the office, met up with my fellow Chicagoans from TWUXX, and had a series of chats with various people about our experiences and our future assignments. For a week, we mostly sat at the beach (a table where people not on assignment tend to sit... it has a palm tree ^.^) We spent some time looking at making a command-line interface for Mingle. It was all our own project, and we didn't make that much headway, although I learned a lot of interesting things about the structure of Ruby gems.
On the second week we worked on a small Rails app with some interesting algorithm problems- this was an assignment, not just a project that we happened to be working on. We were trying to refine the theory behind some not completely understood complexities in the algorithms. Around the middle of the week, I was taken off the project, so I didn't get to see the delivery of the first iteration... but I hear it was good!
I was now shadowing DevOps on a project in Chicago. I experienced conceptual overload several times in my first day there... not only did I learn about new tools, I learned about new concepts and new fields of thought. I enjoyed it very much.
I learned about the brother build systems Hudson and Jenkins and how they were different from Go/CruiseControl, and servers and server structure and I had my first introduction to CentOS, which is a clone of RedHat. I learned how Selenium, a web application testing system, can be run headless on servers. I began to increase my understanding of the structure and means of manipulating of firewalls.
I learned more about databases and mySQL, as well as becoming competent with ssh keys and server access. I learned which directories (on the servers for this particular project) were used for what. I gained an understanding of the complicated filetree of the repository containing the code that our servers were running. I learned what JIRA is (bug/request tracking software), and how useful they can be... and how many fields there are to fill out!!
After some time, I was given a new assignment, in a nearby location... as a DevOps person in my own right, setting up a simple build system. Now I'm learning to use Frank, which is similar to Selenium but for testing iOS applications.
Not only that, but in my copious spare time, I'm working with XNA 4.0 and I've been reading up on the OpenKinect library with an eye to doing something cool. In my personal spare time I've been trying to get my laptop to detect and understand the input from my SparkFun RFID kit, but it looks like I'll need to use Windows unless I discover something new.
Also I bought a new phone, a G2, and I'm enjoying learning my way around its interface and playing with apps.
Friday, April 1, 2011
installing git on CentOS 5.3
(required in order to get many many other useful things)
sudo rpm -Uvh http://download.fedora.redhat.com/pub/epel/5/i386/epel-release-5-4.noarch.rpm
sudo yum install git
that link will change depending on your version of CentOS, and of course it changes over time. Look it up at https://fedoraproject.org/wiki/EPEL
sudo rpm -Uvh http://download.fedora.redhat.com/pub/epel/5/i386/epel-release-5-4.noarch.rpm
sudo yum install git
that link will change depending on your version of CentOS, and of course it changes over time. Look it up at https://fedoraproject.org/wiki/EPEL
Thursday, March 17, 2011
VIrtualBox fullscreen: my favorite guide
http://digitizor.com/2009/05/26/how-to-install-virtualbox-guest-additions-for-a-linux-guest/
Labels:
ubuntu,
virtualbox
Thursday, March 3, 2011
gem list error
I've been getting this error frequently during or after running a process which uses Ruby intensively. So far I have no solution other than restart. It also affects all other gem commands, including gem --version.
$ gem list
line 5: [path]: Argument list too long
line 5: [path]: Unknown error: 0
I'm still looking into how to fix this.
$ gem list
line 5: [path]: Argument list too long
line 5: [path]: Unknown error: 0
I'm still looking into how to fix this.
Labels:
ruby
Tuesday, March 1, 2011
Monday, February 28, 2011
Friday, February 25, 2011
add "mate" to your path in OSX (to call TextMate)
To add "mate" to the path of OSX (i.e TextMate) you could do stuff in the terminal, or you could do
Help > Terminal Usage > Create Link
and achieve the same result. Sometimes the GUI is useful.
Subscribe to:
Posts (Atom)