Panel

Charles Max Wood (twitter github Teach Me To Code Rails Summer Camp)
Eric Davis (twitter github blog)

Discussion

PDFpen for signing contracts
OpenOffice
Git Repositories
Amazon S3
Time Machine
Mozy
Dropbox
Scope Changes/Contract Addendum
Pivotal Tracker
Client Communications
Source Code
Github
Code Ownership
Code Licensing
Assembla
ChiliProject
Hard Drive Encryption
Remote Wipe Vulnerability
Important Client Info
SSH Keys
Salesforce CRM
Chatroom/Skype/IRC Area
Wiki Documents
Virtual Machines
Status Snapshots
Evernote
Final Documentation

Picks

Guerilla Freelancing - 7 Items Freelancers Should Back Up (Eric)
Are You As Busy As You Think? (Eric)
PartyChat (Chuck)
HuBot (Chuck)

 

Hey everybody and welcome to episode 024 of the Ruby Freelancers Show. This week on our panel, we have Eric Davis.

Hello.

And I'm Charles Max Wood from Devchat.tv. It looks like Evan is traveling, and Jeff had some other family commitments, so it's just going to be the two of us this week.

Nice and cozy.

[Chuckles] Yeah, something like that. So this week, we are going to talk about organizing and archiving client materials. And there's actually a question on and the user voice where they were asking about what we do with some of these things. So should we just jump in and get started?

I think the question is really good because we went through a lot of different things, both development side and business side, so we can actually just pick through and talk about what we do and what we really should do, because both of us aren’t perfect on this.

I know. I should get something out to take notes. [Chuckles] I guess we're recording this, right?

Yeah.

Yeah, I should open up on Omnifocus and just do it that way. Anyway, let’s just start at the top, just because some of these are really quick. And generally, I think we can get through some of them pretty fast. So, the first one is the contract, or contract agreement. So what I do is I usually have PDF Pen and I just have a copy of my signature, and I pretty much just paste it in. And so I just save a PDF copy of the contract. I should probably be putting it in Dropbox or something so that I don’t lose it, but I do have a backup of my machine. I actually have several backups of my machine. And maybe we can talk about that in a minute. I'm not too worried about losing it, but yeah, it’d be probably nice to have it in multiple places.

Basically on my laptop, I have three main folders in my user directory. I have temp, which is where downloads and temporary stuff goes. I have dev, which is all my development projects are there, and I have doc. Dev and Doc are Git repositories, and so I'll check stuff into Git and those get pushed to a server. Inside the Doc, I have yet another Git repository for my business documents. And typically, I write the contract, and so I have the template I use. It's in an OpenOffice. Like you, I just put in my digital signature. And I have the OpenOffice file. I save it and print it to a PDF that I

have sent to the client.

And when I get the actual copy back from the client and it's signed with both of us, I put that in there too. So I have the original that I can edit, I have what I sent the client and what I got back. Sometimes I only get back like the signature page from a client, or sometimes they'll pay mail me a paper copy. And if that’s the case, I'll just scan in the paper copy and put it in that same folder. And it's in Git, it gets sent to a remote server. I also have a backup script that actually puts it onto another hard drive and then from there, it sends it Amazon S3. So most of my stuff, client stuff or contract it's like in at least two, sometimes 5 or 6 places.

Right. So you mentioned that you have like a template contract that you send to them, and I've been using the new leaders one that we've mentioned a couple of times that Evan also uses. And it basically says, “If you send the deposit you’ve agreed to the contract…” and I've actually run it through by an attorney and he said that that is fine, and legally binding. So, I usually I don’t have beyond just a copy of the agreement that I've changed the names on for them. I don’t have to collect a signature or anything.

But as far as having different copies in different places, I did mention I do have backup strategy. I have an external drive that’s connected to my machine that I'm running Time Machine on, and I've gotten one that’s big enough for me to actually keep about a month’s worth of backup copies on there. And so, the thing I like about Time Machine is it's fast for like rolling stuff back. And so if it's been within the last month, I've probably got it on Time Machine.

And then I've also got a paid account with Mozy.com. I'm backing up to Mozy as well and I just back up everything. So if push comes to shove and something terrible happens, I can get the stuff back from there. And I also have a lot of stuff in Dropbox. And we'll probably, down the line, talk about some of the things that I keep in Dropbox.

Realistically, even if you don’t get a signed contract back, if there was a legal problem, I'm pretty sure since you sent the contract over email and there's an email record for that, and if they send the contract back or even if there's a check deposit in your account a couple of days later, you can kind of proof that yeah, here’s the chain of trust or whatever.

Yeah, exactly. There's a paper trail. Well, not exactly paper, but you know. I don’t print hard copies or anything of the contracts. I do sometimes get agreements from like sponsors of podcasts and things like that, and so then I have to digitally sign those, and that’s how I handle all of those.

The next one listed here is scope change decisions. And for me, that feels more like project management. Unless you are dealing with a fixed bid where you’ve got a scope of work and they wanna change it, I don’t know that there's really a document to keep track of. Does that make sense?

Yeah. I've done some fixed stuff where we've had to formally write up an addendum to the contract saying, “We're adding hours, we're adding a budget for it. Here's the changes we’d expect to get.” That sort of thing. I basically say like, “addendum to contract on this date” and save it in the same folder. Like you said with hourly stuff and it's kind of just managing in the project, and most of the project management stuff I do has email tracking, so I have emails, to kind of have a paper trail if there's a problem, but that’s usually not a problem at all.

Same here. I've been using Pivotal Tracker, and you can see the history on any of the stories that are in there; so you can see what the changes were to the story, and then it will also show you who approved it and stuff like that. So you get a nice trail there, and I really don’t worry about it. I haven’t been taken any fixed bids, so I haven’t had to do any addendum to any contracts.

Yeah, they are simple. Maybe 1-2 page thing, like what's changing that’s all it is and just signed off by people.

So going down the list, the next thing is design config decisions. So you found x, y, z conflicted with a, b, c, had to go with x, y, z, z, y. I mean, any of that, I just email the client and tell them that, “We had this, and we need to do this. They won’t play nicely together. Here’s how we are going to fix it. It's going to add this much time.”

Same here. A few times, if it's very low-levelly, I'll put in a git commit log. Like, you have to upgrade this version of the library because it conflicted. But yeah, there's not much really. Most of these kind of decisions, hour by hour decisions, you don’t need to really track and organize once they are made. Most people don’t care to look back at them, so it's not as big as a deal as an actual contract where you're down the line. Someone can get sued about it.

The only thing that I see there is that you find something there that will require another addendum to contract, but I think those are even pretty where that you're going to find something there that you're going to have to cover with the contract. Usually the contract is more about results than about design or config or specifics like that anyway.

So the next thing in here is source code. What do you use for source code?

All my source code is stored on a window share. That’s a joke.

[Chuckles] I was trying to decide if I could laugh or not.

no, like I said I have most of my code, I have like a master Git repository that uses sub modules for a lot of it. But on a full project, I'll have its own Git repository for it. I put everything on my own server. I have I think Git hosts I think running on it. Some of the open source stuff, I put on GitHub too as a mirrored copy, and then some clients, they have their own repository. So I end up pushing to like 2-3 places.

And I do this because I started working with Git back when Git would go down a lot and would actually cause to fail because GitHub is offline. So at that time, it was like, “Oh, I have Git. I'll just push it to multiple places.” So basically, whenever I deploy, it usually comes from the client’s repository, or my private one, unless it's a completely open source plugin they are using without any changes, they use like the GitHub version.

Do you ever worry about code ownership if it's on their account?

For the most part, no. I would say my recent work has all been stipulated in my contract that I own it and I'm releasing it to them under GPL V2, which is because I'm modifying the GPL system, and so therefore anything I do has to be GPL. And so technically, I keep the copyright, and I'm licensing it to the client. They don’t care. They just want the software to work so it's not a big deal. But once again, I do a lot of internal systems. I don’t do a lot of the public facing systems.

As far as what I do, I just manage everything on GitHub. That’s primarily because I haven’t had the inclination to go setup my own Git server. I've done it before. I've set up Git on actually several different systems on different employers that I've had before I went freelance, but it's just not… it wouldn’t solve enough pain for me to actually go and do it. I’d rather just pay GitHub $10/month or whatever to manage it for me.

Yeah. It also depends on what you are doing. For me, I have probably over 100 open source plugins now, and so having those times, I probably have a couple of clients that have their own copy of almost every one of those. And so, were talking about upwards of 200 private repositories. That’s really, really cost prohibitive for GitHub, and so I've kind of like, “Okay, I can set up an SSH in Git repository really quickly and really easily.” And that's cheaper and it works good enough. And then by having a backup copy on my server or protected that way. But once again, it's different situations. I work on a lot of small projects.

Yeah, that makes a lot of sense. But I prefer the commercial service. Now, depending on the client, I've had them set up on different ways; some clients have set up their own organization in GitHub, and they setup the repositories under that, and I don’t worry about. Or they'll just get own one off GitHub account, and then they'll host their stuff. They'll pay for private repositories and just manage it that way. In my case, I also have an organization for my own business, and then some of the stuff that I'm working on, I may have it in a personal private repository. I need to just move them all one way or another, but I haven’t.

It has worked out in my favor to actually own the repository as well as the code, because my contract also stipulates I own the code and I license it to you with a nonexclusive whatever, whatever, license. I don’t remember the exact wording, but basically it just says, “Look, you can use this. You can also sell it to other people and whatever. You can treat it like you own it, basically.” But it's only the code that they paid for. And in one case, I have the client that didn’t pay me for about half the work on their project. And the fact that I own the repository meant that I could just cut them off.

And so I have collateral in the code, in half their application that I can hold over them until they can pay me, which I'm not really convinced they are ever going to do, but then they are never going to get the code either. And that’s just part of the deal, but I would dare say that most of my clients have been totally wiling to just go and set up their own GitHub accounts and just manage it that way. But I have done it both ways. I don’t really mind hosting the private repositories for them, as long as they are my client. And then once the contract ends, then I start pressuring them to set up a Git account so that I can transfer ownerships, so that I don’t have to have that counting against the quota that I have for private repositories on GitHub.

I've also looked at Bit Bucket before. I think they started out as Mecurial, but they do Git also. And I'm looking at it, you can get unlimited public and private repositories. You're only charged I think based on the user’s amount. I actually have an account. I haven’t used it. I'm considering using them as my mirror, so if GitHub goes down I can put stuff over here type thing, because with Git, it's very easy to do that, and you can configure your push, so you can push to multiple places with a couple of commands. This might be a better thing for me than actually having my own server and maintaining it all there, because it is kind of a headache to do.

I agree. We had an in-house server when I was working for crimereports.com, and I was the guy that was maintaining it. I don’t remember why the IT guys didn’t wanna deal with it, but they didn’t. So I think it was just that they didn’t wanna be experts in managing a system. Anyway, it was different from all the other systems they were using. And so yeah, I wound up managing it. And for the most part it was fine, but I like change anything or updates change something in particular that made it break, then it was a real headache, so. Other than that, that’s pretty much how I handle source control or source code. I have used other systems too like Assembla, and I think they were subversion, I don’t know if they have Git baked into their stuff or whatever, but they have a lot of nice tools around the project management stuff too. I remember that working up pretty well.

It's kind of what I talked about in the past episode, be flexible. If your client says, “We need to use it this way,” that’s pretty much what you wanna do, as long as they are not using a windows share. Have a certain baseline level standard of you need to use Git or something like that. I need to be able to access it from home. I know a story of one guy which had to drive, I think it was two hours to get in to the company firewall in order to do his work. They wouldn’t even let him get code out of it.

Huh, that’s crazy.

And he was a freelancer too.

Wow. Yeah, I'm pretty inflexible that way. In fact, I have an email when I get an email from recruiters or people looking to hire me, and it always says something to the effect of, “If it's not a contract, and I can’t work from home then don’t bother.” But yeah, that’s really kind of a headache. Anyway, is there anything else you wanna cover with source code, source control?

The only other thing is when you are done with it, so I had a couple of projects where I was using subversion (this was before Git), what I ended up doing, when the project was wrapped up and this was like a year later, maybe 2 years later, I used subversion and actually exported it, so it's like a dump of the repository. It's the same thing with like what a Git clone would give view. Took that and actually zipped it up, put it on to my local backup server here. So I don’t think it's ever going to happen. But when that client comes back to me, this would be I guess five years now, and if they say, “Hey, do you happen to have a copy of that code?” I still have it lying around, taking up maybe 50 Megs of space. With Git, it's not as big of a deal, because you have a full copy of the code. You can kind of slim it down and stuff. But that’s another thing, it's like you need to kind of get rid of your code over time, otherwise, it's like my dev directories it's growing, it's a couple hundred directories inside of there, that I have to kind of pick through now.

Yeah, I've seen that with my own projects. I've only been freelancing for a couple of years here. Most of my contracts have been relatively long term, so I don’t have a bazillion little directories for a little projects that I have done, but it is still a growing thing. I just haven’t had the [unintelligible] I guess at least to get a space, but.

Yeah, I tweeted about it this week, my laptop has basically been running out of space for about a month now, and finally upgraded the hard drive a little bit. It's the kind of thing like it says, “Git check out failed -- not enough disk space.”

[Chuckles] oh, man. Yeah, that's a problem. So what about databases? If you have test data or you have a copy of production data on your system. How do you manage that?

I'm not that good with this. Most of the stuff, I work on this chili project, and so, I have one check out ChiliProject, and then different branches. So in a directory in there, I have a folder called data, and it's separated by client or if I have their data dumps, or if I have their test data dumps in there. And then each client has their own database, whether it's MySQL or PostgreSQL. And I have a heavily, heavily edited database.yml, and so I can just switch a couple like maybe one line will change it from PostgreSQL from client A to MySQL for client B, testing bug X.

So basically all the client data is stored in my databases, and then once again, if my laptop runs out of space, I have to pick through and like, “Okay, this bug was already resolved. I can dump this database. I don’t need it.” Most of the time, the data for one client is identical and have like ten copies of it, but they are varying a little bit based on when I got it, or if I'm testing a specific bug, or doing a new feature, so I’d have a bunch of tables. And then yeah, I drop the tables as I need them, and then I'll go to that data directory and clean out really old stuff, and then that's kind of like, “I'm out of space. What can I get rid of?”

It's kind of the same thing as far as weeding out client projects that I'm no longer working on. I really don’t tend to do it. Typically, what would happen is I'll move to a new machine, and I just don’t set anything up or migrate any data until I actually need it. I have had to get like production copies of production database and things like that, and I'll just get a SQL dump and then dump it in to my database and stuff, but like I said before I really only do that when I have to. As far as test data goes, typically I just have it in my seeds file in Rails. And it's a pretty small set, so it's not something that I'm really worried about.

This is where I fail a lot of is I'm using a lot of production data for clients, because most of the bugs are data related bugs, that’s not actually like application code, and so I have to use production data. I can’t use C data or fake data or anything like that. And that’s where it's kind of a problem, because of the idea of my laptop gets stolen my client data is now on the open. But to kind of work around that, my entire laptop is encrypted or hard drive has an encryption on it, but still it's only one layer there, and that’s what I wanna kind of try to work on. I guess this next year is actually, if I get production data down, run it through a script, that kind of sanitizes it and strips out stuff and then use that as my test data for them, and not actually like the real hardcore production data.

Yeah, that makes sense. In fact, I kind of like that idea, just have something that will sanitize the data, either in the dump or in the database, and you can decide which level you are at, and that makes a lot of sense. I hadn’t really thought about that. But most of the development I do isn’t on the laptop, so I mean, unless somebody breaks in to my house, they are not going to be stealing the machine that I'm doing most of time developing on, so I don’t worry about that nearly as much. Though I do work on a Mac, so I can always remote wipe my computer, or somebody else can remote wipe my computer as you may have heard. You mentioned that before the show, that who was it? It was a tech journalist, Matt something, I think.

I don’t remember the name. That stuff happens quite a bit, I mean this is a pretty public one, but stuff gets leaked a lot. I mean, I'm getting more and more paranoid throughout the years, and so that’s why I like my laptops encrypted, and it actually is kind of a hassle for me to develop on certain things because of the encryption. I'm looking now, at like, “Okay, I need to sanitize the data, and I need to stop keeping as much data on here and start cleaning it off.” And it's just heightened levels of security; it's like threat level orange right now.

Yeah, it was Mat Honan, and he actually posted them on Wired. I'll put a link in the show notes about it. What would you do if somebody wiped your laptop? I guess you have a backup drive, and you are backing stuff up to there on S3?

If someone wipes my laptop, it would suck, but it would not really be a big deal because I have a hard drive with a backup, I have it backed up in S3, and it's incremental and full. And all of those backups are encrypted also. And a lot of my… because I'm using Linux, a lot of the installed Ruby, install this, install that, I have automated. So I don’t have it completely ready because I don’t setup new systems that much, but it's the thing of, I can order a new laptop, and then run a couple of commands, and probably a couple of hours of automated downloading. The laptop is back to where it was. So it's not really that big of a deal for me. I'm more worried about leaking client data, because that’s just a massive fail, a massive suck as a business.

I totally agree. I wonder if there are any tools out there for sanitizing data and databases and stuff. If there's a good way to do that.

I wanna say ThoughtBot did a post on something like this. I think they are using like faker or random data gen, but it's very application-specific because you have to like iterate over all the columns, all the data tables, and you have to know like what should go on this field, what should go on this field. But it's not really that hard; it's just a matter of sitting down and figuring that out. Like for you, I think it will be harder because you work on different projects. But for me, it's like 90% of my stuff is using the same database schema, so I can just write it once and be done.

Yeah, for me it would be a little more involved. But even then, I think you could probably do a general sanitizer app of some kind, that even just went in and basically look through all the tables and said, “This format in this column looks like a credit card. Is it a credit card and do I need to clean it up?”

[Chuckles] And, “Why are you storing a credit card in the database?”

Yeah. You could do the same thing with phone numbers with addresses, names, email addresses, anything like that. You know, you could say, “This looks like you named it first_name. Is this the first name or is this something that we need to monkey with?”

Yeah, you could do it where it just throws a string to fill the column. It's like 255 or whatever. And if it has like the common you would use and you could use them with specialized data. And like I said, the faker game and the random data gem, both of those produce really good data. I actually use those for performance testing; load in 1,000 to a million records and see what the app does.

So it's just a matter of sitting down and actually writing that kind of sanitizer.

Yeah, that would be interesting. Or even just a Rails plugin, and then maybe when you run the rake task, then it can suggest fields, or you can specify the fields and some yaml files or something, but anyway, I think we're getting a little off topic here. So the next thing listed here is notes on the clients environment, such as servers, login info, important directories, where to find things, stuff like that.

Because most of my clients use ChiliProjects or they use my ChiliProject, and both of those come with a wiki. So a lot of that stuff, we put in a wiki. Login information and stuff like that, I actually use, and then .ssh/config in your home directory, you can put in like custom aliases. And so I'll put in like login to server x, I call it as the client name, instead of 123.gateway.rackspace.com or whatever, and then I can put in a custom port, a username and all that. And then I can SSH in, and then I'll use like an SSH key to actually get in without a password. So most of the authentication stuff, I don’t have to worry about.

And then as far as like important stuff on the server, in Etsy, there's an MOTD, which is Message of the Day file. Some version do it differently, but whatever you put in there is pretty much showing on the screen when you log in, like “Welcome to Ubuntu”. So what I've done is I’d put in like, “Hey, the Rails app for this domain is installed at this place, please use this. Use it to deploy. You can find the Git repo here.” Kind of all that stuff that you are going to wanna see right when you log in, especially if it's like, “Hey, we're using Ruby 1.9.3. We're only using Bundler,” that sort of idea.

I like that idea. I generally will setup… I didn’t realize you could put that into the Git config. It's kind of my fault, but.

No, it's in SSH.

Yeah, SSH that’s what I meant. SSH config. And that sounds really, really handy. And then as far as the MOTD again, I have never thought about using it that way. And I really like the approach because essentially what it is, is once you are in the machine, then you have your reminder but all of the relevant information to the application is stored on the server where it's being hosted, and you don’t have to know it, remember it, or worry about it until you are actually on the machine.

Yeah, it's the idea of, “Okay, you need to get on a server.” What you need to know is what the server is, and you can get that from the wiki or the SSH config. Like if you stored it there, once you get on the server, then it says, “Now, you are here, here's where you need to go to do your things.”

Another thing, I don’t see people using this that much, but you can use the doc folder of Rails and throw files in there, and you can actually have rdoc pick them up. And so you can say, “Okay, here's the Git URL. When you clone this, run rdocs and read through the rdocs.” And that’s all the project documentation, and that’s where our servers are, that’s how we deploy, and so it's all selfcontained. So if it ever changes, it gets checked in, and people can see the version.

I've seen that kind of information in the readme or what have you. And yeah, you can always use rdoc to put it on to the doc folder. I hesitate a little bit depending on what the information is about putting even the username and server name out where people can see it. I’d want that to be a little bit more protected than stored necessarily with the code or anything. And with your SSH config setup, do you ever worry about people getting their hands on that?

Not really because the way I look at it is if you put this stuff in the Rails app, if you have a Capistrano deploy in there, it has the username, and it has all that stuff in there anyways. My ssh config you can put the passwords into those, but I don’t. I use SSH keys, so I might have to talk to someone, like an IT on the phone and say, “Okay, tell me what my password is.” I use it for that one time, just copy my SSH key, and then from then on, I forget the password.

And SSH keys are so the way to go.

Yeah. And if you do SSH keys and go to a lot of servers, make one per client at the very least, if not, one per project. That way, if it ever gets compromised or whatever, you can just junk it.

Absolutely. So what about client organization and processes, client info, who's in charge of what, who can get you information on whatever a release process is? You kind of went first on the last one, so I'll jump in on this. I use a CRM. I use Salesforce, and that helps with a lot of that. Another thing that really helps with some of this is just having an overall chat. So either a room on Skype or an I'm or an IRC setup, so that everybody is in the same place and you can ask.

The other thing that really helps with a lot of these is a lot of the time; you'll have some kind of project manager with the client. And so you're really dealing with only one person, unless there’s something specific. And so in a lot of cases, you just ask them for what you need, and they'll get the right person in touch with you. But if you are dealing with more than a handful of or people, and you need to keep it straight, then CRMs are the way to go. And again, having that global chat room out there, so that you can ask the person that you think handles that and then they can point you in the right direction if you want.

That’s kind of what I do. I have a CRM, but I don’t use them much. It's just a big, glorified address book for me. I do a lot of stuff in email. And most of my projects, I have one, maybe two points of contact for the PM. And if I'm working with someone else, we're working really closely together, so I'm not going to forget who they are, or what they are responsible for. And as far as like release process, and any kind of development process, I tried and automate that as much as I can. So I’d put it in Capistrano, and I make it like the default task, and I hook into the stuff there. So you don’t really need to write much of them down; just run Capistrano. Kind of business processes, if their project needs that, that’s kind of where it goes in the wiki. We’d write it as a wiki page, and then try to hook it in with like an issue or a task or something like if we have to do a release every month, we'll make a task for it and link to the wiki page, so we follow the process each time.

I agree with you. Especially on the processes, you can automate it, then you don’t have to remember it. And I mean that in two ways: one is then the process is run the automated process runner. And the other way is if I really do need to know what the process is, I can go look at the automation, and see what the steps are. So if you have to explain it to somebody else, you can just say, “Look, this is how it does it.”

That’s how a lot of stuff starts out is I'll start with like a wiki document, like bullet points of, “Do this, then do this, then do this.” And as slowly as the project needs more automation and more people will come on, we'll kind of actually like, “Okay, lets break this out into script. And then step 1, instead of being paragraph long, we'll run this script. If it errors talk to the PM. Move to step two.”

Absolutely. So the next one is, do you set up VMs or separate environment for each projects, especially if you had to load in a lot of libraries or tools that conflict with your regular environment.

I don’t do this; I want to. Most of my stuff is working on ChiliProjects, so it's 1 or 2 versions of Ruby, the same base code, it might be different branch for a different version, but it's 80% of the same stuff. I've been playing a little with JavaScript and Node, and I've had an old version of Node, and I needed a new version of Node, and then to use Ruby Jasmine, I need a different version. And I've done enough devops that I actually got scripts to set up a server and get it running, and either install Ruby or if I need Node on there, any of that stuff. And so I'm actually really considering for any non-chili project project I pick up, to actually the first thing is set up a clean VM where I dev on, and then I can also use something like that to test the deployment script and deploy to a local VM, get it working, and then push it out to an actual VPS or dedicated server.

And I think with RVM in Bundler, a lot of the library tool conflict is actually going away. In fact on my system, now my system Ruby only has bundler and then everything else was in like gem sets or different versions of Ruby. But before, it will just be really bad; I’d have to uninstall Rails gem by gem, by gem, get to an older version, work on something, and then the next day for different client, I’d have to reinstall the new version of Rails. That happened so many times. It was pretty frustrating.

Yeah, I'm kind of the same way. I generally don’t use VMs at all. On occasion, I have to test something. Because even the deployments are usually pretty simple, and the server setups are usually something that I put together, so I'm using the same tools either way. So I'm using Phusion Passenger, Apache, just basic stuff, memcached for caching and sessions and junk like that. So it's usually pretty homogenous, as far as the setup goes. And that being the case, I really don’t have to test anything if they have some kind of custom setup, that will do that or something like that, then yeah, I'll go ahead and use Vagrant or something to set it up and then run the VM from there and fiddle with it. But honestly, most of the time, I don’t bother with it. I just set things up and run. And the same with Heroku; you just set up the staging environment and make sure it looks like the production environment, then you do your best.

And as far as library or tools that conflict, I'm with Eric on that one. I don’t see it anymore because I'm using RVM and Bundler, I don’t even really use gem sets anymore. I mean, sometimes I do. Some of the older projects do it, because I've setup an RVMRC file in the folder for the project, and so commonly, that's what I'll have. I do like having the RVMRC in there, basically because it's a way for me to communicate to other developers. This is the version that it's developed against, and this is the version of Ruby that’s running in the server, but beyond that, I really don’t worry or bother with it.

So the last one, project status, snap shots, so when you get a call for more work six months later, you remember what you are doing and what the next steps were. So is that like a note to yourself, or some way of remembering where you were at with the project when we come back and say, “We want work done.”

It's kind of like what I was thinking like, “Where did you leave this project off?” And how did it advance after you left it or whatever.

I think part of it is just in the way you manage the project. So hopefully, you don’t have a half done work that’s checked and the master that you're going to have to figure out down the road. I mean, everything in master should be complete. So worst case scenario, then you go look at the story branch for whatever you were working on, and then you can just get up to speed on that.

And then as far as any of the other project status stuff goes, like I said, I've been using Pivotal Tracker, so I'll just go in and I'll archive the project, and then if I need to bring it back, then I will unarchive the project. I'll just bring it back out. So that’s pretty much it. Unless there's something that I'm putting down or picking up the next day, and I wanna make a note to myself, “This where I'm at,” I generally don’t do this at all.

I do this a bit more than I want to. A lot of that is because not even when the project ends, but a lot of the work I do is start and stop. So a client might say, “Hey, let’s work on the prototype, see what we can get going for it.” And then halfway through it, it's like, “Hey, we need you to stop working on that, and start working on something else.” And so it's not in master, but it's in, like you said in a branch, work in progress branch. But I've had that happen where it sat there for like I think like 6

months, maybe even 12 months, so getting back to it I’d actually have to go through to get logs, and reread the actual feature description. And talk to the client and say like, “Okay, is this still how we want it to work?” And I don’t take very good notes about where I leave it off because I don’t know like, “Okay, we are going to stop this on a Friday, so it's time to kind of start writing down where I'm at,” and I feel like I have to do stuff. I don’t have much notice about it.

As far as full projects, most of the time, I'm the only developer on them. So if where I leave the project is pretty much where I'm going to pick it up, and it's pretty easy. I mean, when I try to finish a feature, it's like I wrap it up like I have the documentation and all that stuff in there. So I can go through the Git, see the last 4-5 commits, see how I finish it up, and pretty much come back up to speed of like, “This is where I was at with this.” And usually the client might be using their project management system, and there might be changes in that, so I stopped right now, and since the time that I stopped, to where I started up again, there might be ten new features, but I just skim through these features, talk with them about it, maybe have a conference call, and basically get up to speed that way.

So are there any document things or anything we need to talk about. The only other thing I can think about is that I did mention that I was going to tell you how I use Dropbox in all of these. The thing that I do with Dropbox is if there any files, as far as like design documents or that’s pretty much it, so like mock ups and stuff; I'll set up a Dropbox, and I'll share a folder with the client, and that way they can put stuff in there; they can update it, and then they just let me know what the changes are in those files. And the nice thing about that too is that I can share those folders with subcontractors, and then they have everything that I have, and I don’t have to go and hunt through my email to find it, forward it, and whatever. It's a much better way of going for me. You can do the same kind of thing with Evernote or something like that, but yeah, Dropbox is really the way that I handle that.

Yeah, I've had clients do that, because I don’t do much design work. A lot of my clients do that themselves or contract it out. And so they'll… some of them they'll throw it on Dropbox. I’ve actually had a few of them send me the final versions, and then I'll actually throw it in a Git repository because it's not going to be edited, it's not going to cost a lot of churn. One thing I've had a problem with is if a client takes all these and they like upload to it to the project management system, because then you end up with a whole bunch of things; attached issues, and then like, “Okay, is this the final one over here? Is this the final one over here?” And so, I think Dropbox would be a really good solution for that because you'll always have the latest, and then you can just do I think you can do a link from another website to the actual Dropbox file, because you can make a links now, so that’s probably what I'm going to start doing. But yeah, most of the time, I just wait for the final versions and those are the ones that I use.

Exactly. Any other type of sharing or information that you wanna discus?

There's one. It's basically one of the project is closed out and wrapped up. I talked a little bit about it, but like, a final documentation. I've had to do that for all of my clients, two months ago, when I went on paternity leave, like “Hey, I'm done. I'll be coming back. But in case you need to get to it, or you need to let someone else in, here's all the docs for it.” And so for some cases, I use the wiki for that. And in other cases, it was just email because there wasn’t as much documentation needed. But typically, I try to close out a project by giving them everything they need to get to another developer to get started from like, “This person knows Rails,” to “Okay, they understand the project.”

Well, I don’t think there's anything else, so I'm going to go ahead and move over to picks. So what are your picks?

Okay, my first pick, this is actually from one of Jeff’s newsletters. I thought it was pretty relevant. It's from Guerilla Freelancing – 7 Items Freelancers Should Back Up. There's a couple things in here and we’ve talked about like client contracts, but it also talks about if you have newsletter list or phone contacts of them, you wanna make sure you back it up, and you probably wanna back it up in a way that you can get to it. Like having an XML file all of all your phone numbers for your clients probably not going to help you on your iPhone, so you probably wanna get it backed up to your address book or something.

The second pick is an article I read on the Wall Street journal, it's basically titled Are You as Busy as You Think? It's interesting because it talks about how everyone says they are extremely busy; they're own 24 hours a day, so tired, don’t have any time, all that. And I like the way that it's ended. It's basically instead of saying you don’t have the time for things, you basically say, “It's not a priority.” So you can say like, “I'm not going to edit resume because it's not a priority. Or I'm not going to go to the doctor because my health is not a priority.” So it kind of changes your words around, and makes you really think about it. Not as you don’t have time, it's not a priority. You are not making time for it. I've been actually thinking about that with a lot of things, and it’s really made me look at what I'm doing a little bit differently.

I like that. So my picks, the first pick is I went to the downtown Ruby users group. It's part of the Ruby Users Group Utah, the downtown chapter, which has been around for like two months. The nice thing is they actually do the meetings on Wednesday nights, which means I can go. Anyway, one thing that they were showing off, and this is something that I'm definitely going to set up, is this thing called PartyChat. And basically, it sits on top of Google talk, and you can use it over any XMPP or jabber client. And it sets up a room so that you can share the information and stuff like that.

It runs on Google app engines, and I guess it's pretty fast, but the thing that really sold me on it was you can use HuBot in there, which is the bot that GitHub uses in their Campfire chat. Now, I'm not a huge fan of Campfire, but I do like the idea of having something like HuBot. It was something that went I worked at Mozy, they had like an IRC server that was in the office and so you could join the different rooms and be involved. And they had bots that gave you different status updates on the system and things like that.

And so this is something that’s really appealing to me, especially with some of the projects that I'm working, now I have sub-contractors, it would be really nice to just pull maybe the person that I'm working with at the client, and pull the sub-contractors in that are working on the project, and then have HuBot in there. And so HuBot is then saying, “So and so pushed this up,” or “So and so closed this story in pivotal, and so and so delivered this, somebody just pushed to Heroku, somebody just pushed to this server,” whatever the situation is. Somebody breaks the build, then it tells them that they broke the build. All of that. It just seems like a win for me, so I'm really kind of excited about what this offers. And  I'm probably going to jump in and give it a try, and so I'll be setting that for a couple of the projects that I'm working on. Those are my picks – HuBot and PartyChat.

Cool. And that’s kind of what we talked about if you are going to automate some processes, instead of asking, “When was this closed?” you have to look at it manually with HuBot can do it for you or any other script. That's a lot easier.

The other thing that I liked the guy that was showing it off at the meeting, he actually had it setup, so that HuBot gets the Git hook from GitHub, so that then it goes ahead and deploys to the staging or to production for you. So if you push to master, then it deploys to production. If you push to development, then it deploys the staging, and it tells you about it, and hooks in to all the other stuff that they got going on. So you can also give it commands to actually deploy. So you can say HuBot deploy production, and then it will deploy the production. Anyway, I guess we'll wrap this up.

Thanks for coming, Eric.

Yeah.

I think we had a good discussion. I really hope this helps some folks out. And hopefully, Evan and Jeff can be with us next week.