Programming
Trac + Git
06/02/11 07:57
I recently needed a shared Git "server" for an iOS project since the company standard was, well, some other VCS that really only works on Windows. We could push to it through a Rube Goldberg setup of creating an archive, copying it to a network share, unzip and perform a directory compare, and then one-by-one reconciling the changes to commit.
Not a great way to work for day to day development. Se we started using local git repos and pushing/pulling to each other periodically.
That's great, but there's still value in having a remote repo that's always online and backed up and represents the most recent "truth" of the source.
Anyway, I'm rambling. After some poking around, I ran across the Trac Turnkey Linux appliance. I've used Trac before with Subversion and it's a great system for collaboration that's easy to setup, easy to use, and pretty powerful. Love it. This appliance comes preconfigured with Trac 0.11 running on Apache2 with not only Subversion, but Git, Mercurial, and Bazaar, sample project setups for each, and a script for creating new Trac projects and repos in one step.
Pure. Awesome.
Here's how we set ours up. Remember, this is inside a firewall with only trusted contributors. I wouldn't do it this way if it were more public.
1. Download the ISO and use to install a new Ubuntu server VM (512MB, 1 CPU). I elected not to use LLVM because I don't expect to add space (it's a "working" repo, not the system of record). That decision will bite me later, no doubt.
2. SSH to the new server and run "trac-initproject git my-cool-project". This creates a new Trac project named "my-cool-project" along with a matching shared, bare Git repository.
3. The URL of the Trac site is http://trac.corp.local/my-cool-project (replace the server name with yours) and the public URL of the Git repository it git://trac.corp.local/git/my-cool-project.git.
4. The location of the actual repo on the server will be /srv/repos/git/git-my-cool-project. It's configured to permit public push, but the permissions preclude it. I threw caution to the wind and just granted a+rw. The only people that could access are people that should access it anyway to permissions don't buy much in this setup.
5. I added some Trac users to /etc/trac/htpasswd (the Turnkey guys setup the server so that all of the relevent config files including project configs are linked in /etc - awesome) so that people could authenticate to Trac. Git doesn't care in this setup.
6. On each development machine, just add the public repo as "trac" and have everbody push their master to it.
7. Finally, edit the Trac wiki with Git URLs and some instructions for how to clone, push, and pull.
Maybe one day we'll go all Git and get github:fi to replace the craptastic VCS we have now. Hey, I can dream, can't I?
Not a great way to work for day to day development. Se we started using local git repos and pushing/pulling to each other periodically.
That's great, but there's still value in having a remote repo that's always online and backed up and represents the most recent "truth" of the source.
Anyway, I'm rambling. After some poking around, I ran across the Trac Turnkey Linux appliance. I've used Trac before with Subversion and it's a great system for collaboration that's easy to setup, easy to use, and pretty powerful. Love it. This appliance comes preconfigured with Trac 0.11 running on Apache2 with not only Subversion, but Git, Mercurial, and Bazaar, sample project setups for each, and a script for creating new Trac projects and repos in one step.
Pure. Awesome.
Here's how we set ours up. Remember, this is inside a firewall with only trusted contributors. I wouldn't do it this way if it were more public.
1. Download the ISO and use to install a new Ubuntu server VM (512MB, 1 CPU). I elected not to use LLVM because I don't expect to add space (it's a "working" repo, not the system of record). That decision will bite me later, no doubt.
2. SSH to the new server and run "trac-initproject git my-cool-project". This creates a new Trac project named "my-cool-project" along with a matching shared, bare Git repository.
3. The URL of the Trac site is http://trac.corp.local/my-cool-project (replace the server name with yours) and the public URL of the Git repository it git://trac.corp.local/git/my-cool-project.git.
4. The location of the actual repo on the server will be /srv/repos/git/git-my-cool-project. It's configured to permit public push, but the permissions preclude it. I threw caution to the wind and just granted a+rw. The only people that could access are people that should access it anyway to permissions don't buy much in this setup.
chmod a+rw -R /srv/repos/git/git-my-cool-project5. I added some Trac users to /etc/trac/htpasswd (the Turnkey guys setup the server so that all of the relevent config files including project configs are linked in /etc - awesome) so that people could authenticate to Trac. Git doesn't care in this setup.
6. On each development machine, just add the public repo as "trac" and have everbody push their master to it.
git remote add trac git://trac.corp.local/git/my-cool-project.gitgit push trac master7. Finally, edit the Trac wiki with Git URLs and some instructions for how to clone, push, and pull.
Maybe one day we'll go all Git and get github:fi to replace the craptastic VCS we have now. Hey, I can dream, can't I?
The Right Way to Load a Custom UITableCellView
13/11/10 08:50
Although there are lots of places online to get iOS programming tips, the quality of the information at most places is really pretty low.
For example, I needed to load up a custom UITableCellView from a xib created with Interface Builder. If you poke around online, you'll see several examples that involve loading the xib manually and walking down the object graph until you find a specific class. Fragile, brutish, and totally unnecessary.
The correct way is crazy simple. The xib loader is already expecting to hookup the object graph to the "owner" object (represented by the File's Owner in Interface Builder. If you only use the custom cell in one controller, just expose an IBOutlet for it's class, set your controller as the File's Owner class type, and wire it up in IB.
Let's assume your custom cell class is called MyCustomTableCellView and your controller that needs it is called MyCustomTableViewController. In the controller's header, add a property like this:
@interface MyCustomTableViewController : UITableViewController {
MyCustomTableCellView *customCell;
}
@property (nonatomic, assign) IBOutlet MyCustomTableCellView *customCell;
@end
Notice I'm using "assign" instead of "retain" because I don't want the controller to take ownership of the cell, just hold on to is momentarily so that the tableview can take it.
Synthesize the property and then when you need a new instance of MyCustomTableCellView from the xib, use this code:
[[NSBundle mainBundle] loadNibNamed:@"MyCustomTableCellView" owner:self options:nil];
cell = customCell;
Viola, custom cell view loaded painlessly.
For example, I needed to load up a custom UITableCellView from a xib created with Interface Builder. If you poke around online, you'll see several examples that involve loading the xib manually and walking down the object graph until you find a specific class. Fragile, brutish, and totally unnecessary.
The correct way is crazy simple. The xib loader is already expecting to hookup the object graph to the "owner" object (represented by the File's Owner in Interface Builder. If you only use the custom cell in one controller, just expose an IBOutlet for it's class, set your controller as the File's Owner class type, and wire it up in IB.
Let's assume your custom cell class is called MyCustomTableCellView and your controller that needs it is called MyCustomTableViewController. In the controller's header, add a property like this:
@interface MyCustomTableViewController : UITableViewController {
MyCustomTableCellView *customCell;
}
@property (nonatomic, assign) IBOutlet MyCustomTableCellView *customCell;
@end
Notice I'm using "assign" instead of "retain" because I don't want the controller to take ownership of the cell, just hold on to is momentarily so that the tableview can take it.
Synthesize the property and then when you need a new instance of MyCustomTableCellView from the xib, use this code:
[[NSBundle mainBundle] loadNibNamed:@"MyCustomTableCellView" owner:self options:nil];
cell = customCell;
Viola, custom cell view loaded painlessly.
How Ubuntu Taught Me Not To Fear The App Store
01/07/10 07:10
There’s quite an uproar in parts of the tech community advocating the Android platform over the iOS (iPhone/iPad) platform because Android is “open” and iOS is “closed”. Frankly, I think this idea is misguided. In addition, I believe companies like Google are cynically furthering this misunderstanding in an attempt to manipulate the tech community for PR purposes. I also think this is detrimental to the broader user community and, if successful, a turn we’ll probably regret in the future.
So how could someone who loves open source software and who has contributed to several open source projects take such a counter intuitive position? Shouldn’t I be chanting “Up With Android, Down With iOS?”
Let me tell you why I’m not.
It was Ubuntu that taught me. These days, I won’t recommend any Linux distribution other than Ubuntu to someone who isn’t a unix expert and knows what they’re doing. Even those folks should probably think twice before passing on Ubuntu. Don’t get me wrong; RedHat/Fedora, SUSE, et al are excellent, as are the BSDs. But, Ubuntu has a massive advantage; it’s engineered to be straightforward and simple to use for the majority of use cases and is managed by a community that takes the responsibility to maintain that very seriously.
When you run Ubuntu, the preferred way to get software onto (or off of) it is using the Ubuntu Repository. For GUI users there’s a beautiful app browser that lets you look for applications you might want, see some ratings, and click a button to install if you see something you like. If any updates come out, they’re pushed to you automatically. If you get tired of the app, you can just as easily remove it. This repository is curated; a group of people carefully review anything that goes into the repository to make sure it’s safe, installs cleanly, and so forth before it can be published and signed by Ubuntu. As an Ubuntu user, if you stick with the official repositories, you really don’t have to worry that much about your computer that you’re relying on getting trashed by spyware or malware, your personal data being stolen, your system getting some poorly written piece of crap on that prevents it from shutting down cleanly, running smoothly, or just getting trashed by a half baked app.
Does that mean Ubuntu isn’t “open”? Of course not, it’s fully open in every way that the word “open” can be meaningfully applied to software. What it makes it is “managed” and this is a powerful advantage to the platform in general.
Contrast that with the Windows platform. Even though I can install anything I want onto a Windows machine (and many come with tons of crap preinstalled on them), this doesn’t make Windows an “open” platform. In fact, it’s about as closed as they come. Rather, it makes Windows “unmanaged”. This, to my estimation, is a major failing of the Windows platform and why it is so often the vector for viruses and exploits that have done massive harm to the community at large.
How does this relate to the emerging mobile platforms, Android and iOS? Is iOS really “closed”? Well, it’s based on many open components like BSD, SQLite, WebKit, LLVM/GCC, and hundreds of libraries many of which Apple donates to the open source community and others it activity contributes to. There are open source applications available from the “closed” App Store, like Colloquy. Conversely, Android is also based on similar open components, but like iOS most of the apps that run on it are “closed”. So what’s the difference?
One big difference between the two is that iOS is, like Ubuntu, a managed platform whereas Android is, like Windows, for the most part unmanaged. If you use an iPhone or iPad you can be certain that the primary conduit for installing apps is being managed by a party with a vested interest in keeping is safe, reliable, and reputable. This might mean some hackware isn’t available or you can’t browse to some random site and click the “download” link to install an app, but it does mean that your system is as safe and reliable as you can reasonably expect it to be.
If you do get some app that you want gone, just delete it. You system won’t become littered with half installed bits of broken apps that make it run slowly or cause weird bugs. In a way, your device becomes what us techies call a “production” device. This word has a special meaning in the tech circles because it means a device plays a critical role that someone or something is depending on. It’s locked down from casual modification. New software and updates are applied in a considered manner, and efforts are taken to prevent it from experiencing downtime or sluggish behavior.
After nearly three decades of developing software for and using a computer regularly it’s really sunk in to me that your primary computer is a production device. It needs to be reliable and safe. Downtime or poor performance hurts you. Even having to do mindless and unnecessary maintenance on it (like cleaning out busted uninstalls or worse, wiping it and restoring it) is counterproductive.
Whether accidentally or intentionally, Apple seems to have gotten this resoundingly right with iOS. Google and it’s advocates haven’t figured it out, yet. I hope for the sake of the next generation of computer users, they do.
So how could someone who loves open source software and who has contributed to several open source projects take such a counter intuitive position? Shouldn’t I be chanting “Up With Android, Down With iOS?”
Let me tell you why I’m not.
It was Ubuntu that taught me. These days, I won’t recommend any Linux distribution other than Ubuntu to someone who isn’t a unix expert and knows what they’re doing. Even those folks should probably think twice before passing on Ubuntu. Don’t get me wrong; RedHat/Fedora, SUSE, et al are excellent, as are the BSDs. But, Ubuntu has a massive advantage; it’s engineered to be straightforward and simple to use for the majority of use cases and is managed by a community that takes the responsibility to maintain that very seriously.
When you run Ubuntu, the preferred way to get software onto (or off of) it is using the Ubuntu Repository. For GUI users there’s a beautiful app browser that lets you look for applications you might want, see some ratings, and click a button to install if you see something you like. If any updates come out, they’re pushed to you automatically. If you get tired of the app, you can just as easily remove it. This repository is curated; a group of people carefully review anything that goes into the repository to make sure it’s safe, installs cleanly, and so forth before it can be published and signed by Ubuntu. As an Ubuntu user, if you stick with the official repositories, you really don’t have to worry that much about your computer that you’re relying on getting trashed by spyware or malware, your personal data being stolen, your system getting some poorly written piece of crap on that prevents it from shutting down cleanly, running smoothly, or just getting trashed by a half baked app.
Does that mean Ubuntu isn’t “open”? Of course not, it’s fully open in every way that the word “open” can be meaningfully applied to software. What it makes it is “managed” and this is a powerful advantage to the platform in general.
Contrast that with the Windows platform. Even though I can install anything I want onto a Windows machine (and many come with tons of crap preinstalled on them), this doesn’t make Windows an “open” platform. In fact, it’s about as closed as they come. Rather, it makes Windows “unmanaged”. This, to my estimation, is a major failing of the Windows platform and why it is so often the vector for viruses and exploits that have done massive harm to the community at large.
How does this relate to the emerging mobile platforms, Android and iOS? Is iOS really “closed”? Well, it’s based on many open components like BSD, SQLite, WebKit, LLVM/GCC, and hundreds of libraries many of which Apple donates to the open source community and others it activity contributes to. There are open source applications available from the “closed” App Store, like Colloquy. Conversely, Android is also based on similar open components, but like iOS most of the apps that run on it are “closed”. So what’s the difference?
One big difference between the two is that iOS is, like Ubuntu, a managed platform whereas Android is, like Windows, for the most part unmanaged. If you use an iPhone or iPad you can be certain that the primary conduit for installing apps is being managed by a party with a vested interest in keeping is safe, reliable, and reputable. This might mean some hackware isn’t available or you can’t browse to some random site and click the “download” link to install an app, but it does mean that your system is as safe and reliable as you can reasonably expect it to be.
If you do get some app that you want gone, just delete it. You system won’t become littered with half installed bits of broken apps that make it run slowly or cause weird bugs. In a way, your device becomes what us techies call a “production” device. This word has a special meaning in the tech circles because it means a device plays a critical role that someone or something is depending on. It’s locked down from casual modification. New software and updates are applied in a considered manner, and efforts are taken to prevent it from experiencing downtime or sluggish behavior.
After nearly three decades of developing software for and using a computer regularly it’s really sunk in to me that your primary computer is a production device. It needs to be reliable and safe. Downtime or poor performance hurts you. Even having to do mindless and unnecessary maintenance on it (like cleaning out busted uninstalls or worse, wiping it and restoring it) is counterproductive.
Whether accidentally or intentionally, Apple seems to have gotten this resoundingly right with iOS. Google and it’s advocates haven’t figured it out, yet. I hope for the sake of the next generation of computer users, they do.
App Store, Here We Come!
14/03/10 14:54
Well, it’s no concept-to-app-store-in-one-week hit, but my first commercial iPhone app is getting really close to ready for submission to the app store!
