I had trouble cloning a git repo between my home iMac and work MacBook Pro, both running Snow Leopard.It should be as easy as (porkchop-sandwiches is my work machine name. That's right.):git clone ssh://tony@porkchop-sandwiches.local/~/work/repo But that was failing with:bash: git-upload-pack: command not found
fatal: The remote end hung up unexpectedlyIt sounded like the problem was that when logging into ssh I wasn't getting my work machine's user's path, which had all the git stuff in it. This is what I googled: http://stackoverflow.com/questions/225291/git-upload-pack-command-not-found-how-to-fix-this-correctly, and sure enough this command showed that my PATH wasn't what I expected: ssh tony@porkchop-sandwiches.local echo \$PATHI tried the solution at stackoverflow, by symlinking .profile to .bashrc but it didn't work even though the PATH was now correct. I don't know what was going on, but one of the other possible solutions on the stackoverflow lead me to this: http://kerneltrap.org/mailarchive/git/2008/6/18/2159464, which I then did, and it then did work. It basically forces SSH logins to execute that custom script as the command, which figures out whether to load .profile or not based on if there was a command passed, and then executes the original command if there was one. I'm off to the races now!
Wednesday, December 23, 2009
Tuesday, December 22, 2009
The Teavana Perfect Tea Maker is Awesome.
It makes one cup of loose-leaf tea and it's so clean and easy to use. Much better than a tea ball and quicker and cleaner than a tea pot.
Here's a link: (http://bit.ly/3umdSF)
Friday, December 18, 2009
Bacon and eggs.
Usability is a clementine.
Usability is a nebulous word that we hear a lot about in my industry. I'm not sure what it is, but I know what it looks like - that kind of thing, you know? It's something we're supposed to make more of, though, that's for sure. In so far as we can be objective about it, it's sort of a utilitarian view (http://en.wikipedia.org/wiki/Utilitarianism) of devices and software and the things that we interact with every day.
When I was at Web2.0 San Francisco last spring I heard a good definition of usability. John Maeda (http://www.maedastudio.com/index.php) said that usability is a Forever Stamp. I like that. A Forever Stamp increases usability by getting more things out of the "user's" way. When someone wants to mail something they want to mail something, not check to see if they have to attach a stamp and a half or paste a quarter on their envelope. They don't have to worry the whole time the thing is in the mail. They just put on the stamp and send it. It's goal oriented; it doesn't expose more of the inner workings of the system (e.g. stamp price changes) than it needs to.
Here's another take. Usability is a clementine. Who doesn't like oranges? Oranges taste great. At least the juicy part does. The pulpy stuff that sticks to the orange as you peel it isn't that great. Oh, and peeling is a pain. They even make special tools for it. And by the time you get done you're up to your elbows in sticky orange juice and half of the orange is crushed.
Clementines are not that way. There's nothing left behind from the skin. It's small enough that you can just zip it open and eat it. If you're really hungry, have two. Peeling is super easy too. I routinely peel one open one-handed as I drive to work.
Oranges were designed by a big corporation. They wanted to make them big, so they look like more of a deal. They wanted to seal in the good stuff so they really stuck that skin on there. They wanted to put seeds in there so there could be more oranges all over the land. Oranges are there for oranges' sake.
Not clementines. They're just for eating.
Moving, but not far
Hey, to anyone who still reads this thing, I'm moving my blog to my Posterous. I'll probably have similar things to say there, but luckly Posterous will post to blogger, so if you do end up here, all the posts at the new blog will show up here.
I'm Back!!
Wow. This is going to look weird alongside the last post, but hey - it's my own fault for not posting more often.
Anyhow - yea, I'm back at EffectiveUI. I've learned a lot and grown some (like an inch), and I'm happy to be back with my friends. It feels like coming home.
Good times.
Anyhow - yea, I'm back at EffectiveUI. I've learned a lot and grown some (like an inch), and I'm happy to be back with my friends. It feels like coming home.
Good times.
Tuesday, May 19, 2009
thillerson checked in at Brightkite HQ
I'm now a mobile developer for Brightkite. I'm going to be working on the existing mobile apps that we have, specifically for iPhone, and also getting a few new ones out to the peoples.
It's going to be awesome. If you're not already on Brightkite, you should be, and once you are, friend me as thillerson
It's going to be awesome. If you're not already on Brightkite, you should be, and once you are, friend me as thillerson
Friday, May 15, 2009
Number 8
I'm number 8.
That's an important number to me, and has been for three years now. I was the 8th person to join on to a small, merry band of nerds and put my own desk together at 18th and Grant in May of 2006. It's been a great ride and it's taken me places I never thought I would go.
Today is my last day at EffectiveUI. I'm not leaving because I've grown tired of working with these guys or because I don't believe in EffectiveUI anymore, because I haven't and I still do. If I could still work with the people I've worked with the last three or so years forever, I would.
I'm leaving because I'm burnt out dealing with client work, that's all. I'm going to another company (which I'll blog about later) which will let me focus on a product I believe in and continue to make it better iteration after iteration - not just until the budget runs out. It's always tough when you want to do more and take a project to the next step and the next step after that, but business realities get in the way. I know that the product world has as many problems as a service company, but I'm ready to meet them head on now.
It's tough, but it's a good choice for me. I'm glad that I'll only be 5 blocks away from EUI, so I'll be stopping in regularly and making sure I don't lose touch. I hope that my new company can continue to be a client of EffectiveUI too.
I was number 8!
That's an important number to me, and has been for three years now. I was the 8th person to join on to a small, merry band of nerds and put my own desk together at 18th and Grant in May of 2006. It's been a great ride and it's taken me places I never thought I would go.
Today is my last day at EffectiveUI. I'm not leaving because I've grown tired of working with these guys or because I don't believe in EffectiveUI anymore, because I haven't and I still do. If I could still work with the people I've worked with the last three or so years forever, I would.
I'm leaving because I'm burnt out dealing with client work, that's all. I'm going to another company (which I'll blog about later) which will let me focus on a product I believe in and continue to make it better iteration after iteration - not just until the budget runs out. It's always tough when you want to do more and take a project to the next step and the next step after that, but business realities get in the way. I know that the product world has as many problems as a service company, but I'm ready to meet them head on now.
It's tough, but it's a good choice for me. I'm glad that I'll only be 5 blocks away from EUI, so I'll be stopping in regularly and making sure I don't lose touch. I hope that my new company can continue to be a client of EffectiveUI too.
I was number 8!
Tuesday, May 5, 2009
RailsConf 09: Flex on Rails with RubyAMF
RailsConf has been a fun time so far. It's halfway through the second day, which is the first of regular sessions. I went to the tutorial sessions on Chef and Sinatra yesterday and caught up on some things I've been behind on, like Rack.
On Thursday I'll be talking at 10:45 on Flex and Rails using RubyAMF. I'll describe how things fit together, workflow, and all the basics that people may have heard before, but also spend a little time on the future and begging for help.
Here are links to the slides and code
http://www.slideshare.net/thillerson/flex-with-rubyamf
http://github.com/thillerson/preso_code/
On Thursday I'll be talking at 10:45 on Flex and Rails using RubyAMF. I'll describe how things fit together, workflow, and all the basics that people may have heard before, but also spend a little time on the future and begging for help.
Here are links to the slides and code
http://www.slideshare.net/thillerson/flex-with-rubyamf
http://github.com/thillerson/preso_code/
Sunday, March 29, 2009
Web 2.0 version 3 (for me)
I'm fine tuning (read: writing) my examples for my Tuesday session at Web 2.0 "Building Your First Android Experience". Pretty soon I may even getting around to packing.
I can't believe it's been two years since my first Web 2.0. And now I get to talk about Android! Last year I ran a panel, which was a lot of fun, but I'm better at geeking out with codez.
For anyone who's looking ahead to the session, you can find the slides here: http://www.slideshare.net/thillerson/first-android-experience and the code here: http://github.com/thillerson/first_android_experience.
If you're going, whether you get a chance to see my session or not, make sure you drop by booth 715. Anthony Franco will also be speaking along with Michael Clark of Photobucket, which you can read about at Anthony's blog.
See you there.
I can't believe it's been two years since my first Web 2.0. And now I get to talk about Android! Last year I ran a panel, which was a lot of fun, but I'm better at geeking out with codez.
For anyone who's looking ahead to the session, you can find the slides here: http://www.slideshare.net/thillerson/first-android-experience and the code here: http://github.com/thillerson/first_android_experience.
If you're going, whether you get a chance to see my session or not, make sure you drop by booth 715. Anthony Franco will also be speaking along with Michael Clark of Photobucket, which you can read about at Anthony's blog.
See you there.
Wednesday, March 4, 2009
Slides and Codes from my 360|iDev Talk
Thanks for everyone who made it to my talk on Persistence for the iPhone. 360 Conferences are always great, and I had a great time and learned a lot. Hopefully my session helped out a few people. Again, you can get the code here: http://github.com/thillerson/grocery_getter/ And here are the slides:
Monday, March 2, 2009
At 360|iDev
I've been remiss in blogging about 360|iDev, but here I am. I'm really stoked about learning more about the platform and confirming suspicions about the right way to do things. So far it's looking good.
A bit about my session on Wednesday at 10:00. I'll be talking about NSUserDefaults, Settings bundles, and the "naked" SQLite3 C API. Then I'll go on to talk about FMDB which makes things a bit easier and also supports Rails-style migrations with FMDB-migration-manager. Then we'll see how ActiveRecord for iPhone works to make persistence dead simple. I hope this dovetails nicely with the talk Jeff LaMarche's talk on Tuesday, covering SQLitePersistentObjects.
More to come.
A bit about my session on Wednesday at 10:00. I'll be talking about NSUserDefaults, Settings bundles, and the "naked" SQLite3 C API. Then I'll go on to talk about FMDB which makes things a bit easier and also supports Rails-style migrations with FMDB-migration-manager. Then we'll see how ActiveRecord for iPhone works to make persistence dead simple. I hope this dovetails nicely with the talk Jeff LaMarche's talk on Tuesday, covering SQLitePersistentObjects.
More to come.
Wednesday, February 11, 2009
Dear Flex, Aesthetics Matter
So, as you may or may not have noticed, there's a little bit of a flap in the Flex community. You can read more here, but the short story is that to make Flex 4 compatible with Flex 3 code, since they may need to be used alongside eachother, Adobe's plan is to prefix Flex 4 classes with Fx to avoid namespace collisions with Flex 3 classes.
For instance: Flex 3 -> <mx:Button>, and Flex 4 -><mx:FxButton> <FxButton>
I understand the problem a bit - most of it has to do with difficulties matching classes with CSS definitions to map to the classes, as I understand it. I appreciate how this could be a problem, but my position is simple. It's a slippery slope. Please, Adobe, don't ruin the good thing you have going, especially as you start to think about other places the Flex language could be used.
Here's what I mean. Look at this mess:
That's a simple, centered, horizontal container with two components: a label and a button, in Android's layout markup. It centers its children and is aligned center in its parent. In a lot of ways, it looks similar to Flex. The tag names correspond to Android framework classes. As far as that goes, it’s simple to see what’s going on here as you read and try to find your place. But look at the android: namespace AT THE ATTRIBUTE LEVEL. Ugly. I’d go so far as Fugly. Also, are attributes camelCased or snake_cased or both? Each one is different. There’s even a android:layout_gravity and an android:gravity. I love Android, but its layout is a mess.
For contrast, here’s a similar layout in Flex:
See how much more clean that is? There are a few magical incantations (from a n00b’s perspective) like horizontalCenter=”0” - they’ll have to remember how some of the layout rules go, but the rest is pretty intuitive, and there’s way less boilerplate. In 99% of the cases in Android you HAVE to specify layout_width and layout_height or the precompiler complains at you. Why? No sensible defaults is one mark of a bad framework.
Someone once told me a heuristic for recognizing a good framework: When writing code, if you don’t remember what you need to write then guess. If you’re right, it’s a good framework. If you need documentation until you have it by rote, it’s not a good framework. Flex is a good framework. You’re generally rewarded by being able to intuitively guess what the right attributes are.
I chose Android’s layout language to compare because it’s particularly nasty, I think. If I knew enough HTML/CSS, I’d compare that too, because I think it’s way too overwrought. And anyway, two languages where positioning is in one language and the containers are in another? How dumb is that?
My point is that Flex, for any other faults people can pick out about it, has layout DOWN. It’s the best declarative layout language I’ve had experience with. Bruce Eckle agrees, and says “Flex is a DSL for building UIs” (paraphrased).
Now, does Adobe ruin this whole thing when they add Fx prefixes? No, not catastrophically, but like I said, it’s a slippery slope. Every concession that clutters the language puts a dent in the area where Flex really shines. As a developer that matters to me. We can look forward to a time where Flex is available as a layout language on more than just the web, and if I had the choice, I’d use Flex over Android’s layout language if I could, because I have to speak this language day after day, and I’d rather get my point across as quickly as possible, because that impacts my efficiency, my peace of mind, and ultimately how hard I have to work to build good user experiences, which is the goal we all share.
It’s been said before, so look around for it on the web: Aesthetics matter. (here's one quick let-me-google-that-for-you) Adobe, please keep in mind what makes Flex the best layout language, and don’t ruin it, even a little. Stay strong.
For instance: Flex 3 -> <mx:Button>, and Flex 4 ->
I understand the problem a bit - most of it has to do with difficulties matching classes with CSS definitions to map to the classes, as I understand it. I appreciate how this could be a problem, but my position is simple. It's a slippery slope. Please, Adobe, don't ruin the good thing you have going, especially as you start to think about other places the Flex language could be used.
Here's what I mean. Look at this mess:
<LinearLayout
android:orientation="horizontal"
android:layout_width="fill_parent"
android:layout_height="wrap_content"
android:layout_alignParentCenter=”true”
android:gravity="center">
<TextView
android:layout_width="wrap_content"
android:layout_height="wrap_content"
android:textAppearance="@style/small_grey_bold"
android:text="@string/button_one_title"
/>
<Button
android:id="@+id/button_one"
android:layout_width="wrap_content"
android:layout_height="wrap_content"
android:text="@string/button_one_label"
/>
</LinearLayout>
That's a simple, centered, horizontal container with two components: a label and a button, in Android's layout markup. It centers its children and is aligned center in its parent. In a lot of ways, it looks similar to Flex. The tag names correspond to Android framework classes. As far as that goes, it’s simple to see what’s going on here as you read and try to find your place. But look at the android: namespace AT THE ATTRIBUTE LEVEL. Ugly. I’d go so far as Fugly. Also, are attributes camelCased or snake_cased or both? Each one is different. There’s even a android:layout_gravity and an android:gravity. I love Android, but its layout is a mess.
For contrast, here’s a similar layout in Flex:
<mx:HBox
width="100%"
horizontalCenter="0"
verticalAlign="middle"
horizontalAlign="center">
<mx:Label styleName="small_grey_bold" />
<mx:Button id="button_one" label="{button_one_label}" />
</mx:HBox>
See how much more clean that is? There are a few magical incantations (from a n00b’s perspective) like horizontalCenter=”0” - they’ll have to remember how some of the layout rules go, but the rest is pretty intuitive, and there’s way less boilerplate. In 99% of the cases in Android you HAVE to specify layout_width and layout_height or the precompiler complains at you. Why? No sensible defaults is one mark of a bad framework.
Someone once told me a heuristic for recognizing a good framework: When writing code, if you don’t remember what you need to write then guess. If you’re right, it’s a good framework. If you need documentation until you have it by rote, it’s not a good framework. Flex is a good framework. You’re generally rewarded by being able to intuitively guess what the right attributes are.
I chose Android’s layout language to compare because it’s particularly nasty, I think. If I knew enough HTML/CSS, I’d compare that too, because I think it’s way too overwrought. And anyway, two languages where positioning is in one language and the containers are in another? How dumb is that?
My point is that Flex, for any other faults people can pick out about it, has layout DOWN. It’s the best declarative layout language I’ve had experience with. Bruce Eckle agrees, and says “Flex is a DSL for building UIs” (paraphrased).
Now, does Adobe ruin this whole thing when they add Fx prefixes? No, not catastrophically, but like I said, it’s a slippery slope. Every concession that clutters the language puts a dent in the area where Flex really shines. As a developer that matters to me. We can look forward to a time where Flex is available as a layout language on more than just the web, and if I had the choice, I’d use Flex over Android’s layout language if I could, because I have to speak this language day after day, and I’d rather get my point across as quickly as possible, because that impacts my efficiency, my peace of mind, and ultimately how hard I have to work to build good user experiences, which is the goal we all share.
It’s been said before, so look around for it on the web: Aesthetics matter. (here's one quick let-me-google-that-for-you) Adobe, please keep in mind what makes Flex the best layout language, and don’t ruin it, even a little. Stay strong.