Finally did some housekeeping here. Some updates, etc. Let me know if things are broken.
|
||||
|
Finally did some housekeeping here. Some updates, etc. Let me know if things are broken.
Enter Virgin’s broadband2go service. The usb adapter costs ~145 and includes a micro SD card slot (lets you use the thing as a thumb drive). The device is the Novatel MC760 (pictured). The pricing is decent for my needs as well (they’re steep for heavy use, but I’m not a heavy user). The pricing ranges from 10.00 for 100mb to use in 10 days, up to 60.00 for 1G to use within 30 days. In my mind, paying 10 bucks for a few days of light net usage occasionally isn’t too bad. The speed is definately usable for browsing, and shell work. I haven’t taken the time to run a bandwidth test on it. One note, if you use a Mac you’ll need a windows box to get the device activated (I was able to use an XP vm in fusion). Once activated it works great. The device comes with drivers that will install the first time you plug it in. I recently picked up a new iPhone. The 3gs is quite speedy and definitely an improvement from my 1st gen phone. I wanted to be able to post videos to twitter (now that the phone takes video, why not?) A few of the iPhone twitter apps are claiming they’ll support it in the future, but none do now. After a bit of digging I ran across posterous. Posterous is fairly cool. You email your media to post@posterous.com and it adds it to a web-page based on your email address. When I send mail from my personal gmail account, a post is created on baltdad.posterous.com. I have configured that account to automatically post to my twitter feed when anything is posted. So, from my phone, I mail video to post@posterous.com and stuff shows up on twitter. Kinda cool. Estimating time for tasks and generating an overall project schedule can be painful. I always feel like there are too many educated guesses that go into schedules and estimating time. Estimates range from very educated, to almost complete guesses. Sometimes the estimates are dead on, most of the time they are pretty close. However, there always seems to be a handful in every project that are really off. These bad estimates are what cause people to work 80 hour weeks. Below are some strategies that may make the process of estimating and scheduling more accurate and less painful. Estimation/SchedulingIf you write software for someone else, chances are very good that you’ve had to guess how long a given activity will take. The only real advice I’ve ever received on the topic is probably similar to advice you’ve heard. “Take a guess, multiply by x, and that’s your estimate”. This is a really crappy way of generating estimates. The problem is mitigated a bit because most of the time estimation of a large project is made up of a ton of small pieces that are estimated separately. Hopefully under-estimation in some areas will be countered by over-estimation in others. However, this is still just wishful thinking. Sometimes it works, sometimes it does not. When it does not, the result can be painful. In my environment, it’s important to limit access to the vcs repository. We need to limit general access to the code, commit access on different branches, as well as the ability to create branches in certain areas. In this post I’m going to look at how to handle permissions to lock down/allow different operations. Here is the repository structure I’m working with:
Just my trunk branch in the repository. All of these files (the .bzr, the directories etc.) are owned by me. I should be able to do anything I want in the repository. Like creating a new branch. So, I have my trunk branch, and my first release branch in the repository.
Testing with various permissionsBelow is a table of various permission settings and the directory/files I applied the permissions to. I chowned all of the files to root:wheel and messed with the global permissions. In actual production you’d want to use some combination of group permissions/setuid bits/umasks to make sure everything works. So, when I list the permissions below, I’m only referring to the permissions I had on the specified directory/set of files. x was only ever set on directories. I just setup a Downloads page. Currently there are two files there. wp_backup.sh, simple script to backup a wordpress install. Good for running out of cron. moveTV.pl, this helps to organize any episodic files with the general filename of name.s00e00.ext. Builds a sane directory hierarchy and normalizes filenames etc. I use moveTV.pl to automate putting content in a location where TVersity/Connect360 can find it. I design user interfaces for a living, it is a strange blend of code, art, and guesswork. I want my interfaces to be useful, visually appealing, and functional. I’m writing software that people are using to do their job. As such, I want to provide an interface that allows my users to do their jobs as easily as possible. What may seem useful for one group of users may not be useful for another group of users. Trying to guess what people want to do, how they want to do it, and what results they want can be very challenging. While there are definitely wrong choices, I don’t believe it’s possible to satisfy everyone. Some people prefer Gmail, others prefer Yahoo Mail. I don’t think Google or Yahoo made mistakes that drove people away I just think that users have different preferences. To develop effective interfaces, you have to figure out who your users are and provide them an interface they want to use. Putting a good set of UI mockups in front of your users, or proxies for your users, can help determine which designs will work, and which designs won’t. MockupsI’ve used two basic strategies for developing UI mockups. First is hand drawing/using some tool like visio. Hand drawing is fairly inflexible, and the tools I’ve used have been fairly clumsy. I’d love to use something that is as quick as hand drawing, that still has the flexibility of using software. A second method of generating mockups is to write user interaction code to drive the mockups. While this method is also time consuming, ideally you will end up with some usable code. When you show the design to the user, you can actually demonstrate how things will work in a live environment, this too is a good thing. If your initial design is too far away from what the user wants, you may end up having to throw away work you were hoping to use later. I know we don’t have time for this in our organization, I doubt others do either. I think it’s useful to develop a set of hand drawn/computer drawn mockups to help present different design options to your potential users. Once you have an idea of what they like/dislike, you can start working on the coded interaction. This way, you are helping to ensure that you are effectively using your time. I started my series about bzr as an excuse to teach myself something that may be useful at work, and as a way to see if I enjoyed writing content. Which, for now, I do. I was using blogger, and quickly got fed up with the lack of options, and a fairly frustrating editing experience. So, I started to look into other options. I don’t think I’ve put a site online for personal use/work since 1998 or so. This project also served as a way to see how things are done these days. It’s been a fun experience. First StepsAfter doing some research I ran across Linode for my hosting solution. They were offering everything I wanted for not a ton of money. I get a pretty fast box, with 36oMB of ram, 12G of disk an 200G a month of transfer. This seemed like more than enough for me. I get full control over the machine; I can reboot/reinstall/do whatever I want. They even provide a remote console in case something goes wrong. They give you 10+ common linux distributions to choose from for the base install. The process was as easy as: pay them, pick your distro, click go. 30 second later I had my vanilla install. Using push/pull with bazaar. Before I started playing around with bazaar I spent a little bit of time with git. Since my background has been entirely CVS I thought that push and pull were generally “special” operations in newer vcs systems. It turns out, in bazaar push and pull do nothing other than manage mirrors of branches. If I’m sitting in a branch and issue a bzr push command, I’ll end up with a mirror of the current branch in the push target, like so:
I now have a branch called myBranch.mirror in my BZR directory. I’m going to take a look at it now.
At this point, it appears that a pushed branch is really no different than a branch that you’ve made using the branch command. You can use push and pull to keep the mirror in sync, as long as the branches have not diverged. A branch is considered to be diverged if there is a check-in in the dest that is not in the source. You can work around this by merging the dest onto the source prior to running the push, or by using –overwrite command that will overwrite the information in the target. One thing I’m starting to notice is that there are many ways to get to the same place with bazaar. bzr branch/bzr bind is identical to bzr checkout while bzr checkout/bzr unbind is identical to bzr branch. I suspect that there are options to checkout/branch/bind/unbind that makes the operations a little more convenient but they really aren’t dramatically different commands. I think that push/pull fall into this camp. I don’t think they do much that you can’t accomplish with branch/commit/update, but they may let you think about what you’re trying to accomplish in a different way. Below are a number of other commands that I’ve mentioned but haven’t really talked much about. I’m not going to go through examples, just describe what they do. In the third part of this series on Bazaar I’m going to spend some time examining repositories. The docs seem to indicate that these really facilitate sharing branches. I was going to cover repositories and push/pull, but this seems like enough for now. RepositoriesAccording to the bzr documentation a repository is nothing more than the database that holds all of the branch data. When you run bzr init, you create a repository within your branch (the .bzr directory). There is also what the manual calls a shared repository, these are created by the bzr init-repository command. A shared repository allows multiple branches to share the same database. This can yield some space savings, as well as keeping everything organized. I suspect that this organization can aid in keeping a sane permissions model. We’ll look at that in a later post though. For now, let’s start playing around with repositories. First I’ll create a repository. Remember, myRepository can use any of the remote URI specifications that Bazaar supports.
The –no-trees option tells init-repository to not create a working-tree of the branches within the repository. Since we won’t be working in this directory, the –no-trees option makes a ton of sense. |
||||
|
Copyright © 2010 baltimore_dad - All Rights Reserved
|
||||