This is not programming tips, as such. But perhaps you'll find it amusing. You've heard of the Fantastic Four, but what about the Git Five?
Tuesday, October 26, 2010
Sunday, September 12, 2010
I took One Photo Every Minute
... using this app I made. Entitled "One Photo Every Minute." (get it from the Android market! ... unpublished, read on.)
I used a duct-tape-and-goggles thing to attach my phone to my forehead, then took a walk to the wonderful Viet Wah Asian grocery store. Some things I learned:
- there's more work to be done on the app if I want to be able to take daylight photos. I only want them to be recognizable, not museum-quality, but most of the ones outside are super overexposed. Even if I Feel them Lucky on Picasa, they're white-outs.
--- Unfortunately, I won't be doing this work on the app. The fun part is done, and this was an experiment, not an app I want to maintain. More info on this other post (especially the comment string)
- inside photos are pretty good. Especially after you Feel Lucky. (props to Google for popularizing this phrase, and props to Picasa for naming their "insta-fix" feature after it. I wish this were in more google properties. Analytics: Feel Lucky and it gives you a random cool fact about your site's traffic. Chrome: Feel Lucky and it takes you to a random page on the internet. Google Maps: does this.)
- the app crashes all the time. If you just want the end product of something, and you don't enjoy the process of making it, let someone else do it. I'm sure people have done this better than me. (and maybe without goggles, duct tape, and a phone on their forehead.)
- nobody- nobody!- looks at you weird if you have goggles, duct tape, and a phone that goes "click" every minute on your forehead. This was probably the most surprising thing I learned.
- the photos (the ones that are visible) are really interesting to look at. It gives you a very real sense of time. The walk felt like it took longer than the grocery shopping, but they were about the same amount of time; the photos prove it.
Anyway: the photos! In two parts because I paused it for a few minutes in between.
Part One
Part Two
Hope you find these as marginally interesting as I did!
I used a duct-tape-and-goggles thing to attach my phone to my forehead, then took a walk to the wonderful Viet Wah Asian grocery store. Some things I learned:
- there's more work to be done on the app if I want to be able to take daylight photos. I only want them to be recognizable, not museum-quality, but most of the ones outside are super overexposed. Even if I Feel them Lucky on Picasa, they're white-outs.
--- Unfortunately, I won't be doing this work on the app. The fun part is done, and this was an experiment, not an app I want to maintain. More info on this other post (especially the comment string)
- inside photos are pretty good. Especially after you Feel Lucky. (props to Google for popularizing this phrase, and props to Picasa for naming their "insta-fix" feature after it. I wish this were in more google properties. Analytics: Feel Lucky and it gives you a random cool fact about your site's traffic. Chrome: Feel Lucky and it takes you to a random page on the internet. Google Maps: does this.)
- the app crashes all the time. If you just want the end product of something, and you don't enjoy the process of making it, let someone else do it. I'm sure people have done this better than me. (and maybe without goggles, duct tape, and a phone on their forehead.)
- nobody- nobody!- looks at you weird if you have goggles, duct tape, and a phone that goes "click" every minute on your forehead. This was probably the most surprising thing I learned.
- the photos (the ones that are visible) are really interesting to look at. It gives you a very real sense of time. The walk felt like it took longer than the grocery shopping, but they were about the same amount of time; the photos prove it.
Anyway: the photos! In two parts because I paused it for a few minutes in between.
Part One
Part Two
Hope you find these as marginally interesting as I did!
Monday, August 2, 2010
The chemical high of programming
Know what I'm talking about? I've gotten it when iterating quickly on something I know how to do, or something I almost know how to do. It's addictive and energizing, and the only thing that makes coding for long hours possible. Perhaps this is "flow."
I think I should keep track somehow of what causes this state. Today it was writing "hello world" using a couple of new technologies, and in that sense, it sounds quite flowy: surfing on the edge of my abilities.
It brings up a lot of questions, though:
- how can I cause this flow more?
- why don't I get it more often already? (I think it is because I am often trying things that are too hard.)
- will it bring me lasting job satisfaction to aim for more flow? (instead of whatever it is that I'm aiming for now, which is "doing what needs to get done", I guess. I think the answer to this question is yes.)
- will I keep learning if I aim for more flow? (I think the answer to this question is "yes, and stop asking so many worried questions.")
Programmers out there, do you know what I'm talking about? And non-programmers, do you get the same thing?
I think I should keep track somehow of what causes this state. Today it was writing "hello world" using a couple of new technologies, and in that sense, it sounds quite flowy: surfing on the edge of my abilities.
It brings up a lot of questions, though:
- how can I cause this flow more?
- why don't I get it more often already? (I think it is because I am often trying things that are too hard.)
- will it bring me lasting job satisfaction to aim for more flow? (instead of whatever it is that I'm aiming for now, which is "doing what needs to get done", I guess. I think the answer to this question is yes.)
- will I keep learning if I aim for more flow? (I think the answer to this question is "yes, and stop asking so many worried questions.")
Programmers out there, do you know what I'm talking about? And non-programmers, do you get the same thing?
Sunday, August 1, 2010
New Android App: One Photo Every Minute
It's an app that takes one photo every minute. Or every 5 seconds, or 10 minutes, or whatever. Wow! Imagine the possibilities!
(EDIT: it's unpublished from the market now because it crashed a lot.)
And it was a surprising pain! Some tips that might spare you some pain:
- don't try to use the camera without a preview. It might work, but I feel like some of the developers might have been assuming a preview. (all example usages of the camera, in docs and ApiDemos include a preview.) At any rate, using a preview surface gives you a couple of callbacks that make it easy to manage the camera resources.
- you might get cryptic crashes or ANR's. I don't feel confident that One Photo Every Minute is 100% crash free, even on the Nexus One I was testing it on. This is awful.
Some general thoughts:
- At work, on servers, we use Guice and dependency-inject everything. I tried to do the same here, and it was way overkill. You can, and should, easily bang out a couple thousand lines of code without doing any DI. (this means most of your code won't be unit-testable. I'm okay with that. No, this doesn't scale well.) Maybe I'll get into specific issues later.
- Model-view-controller is a nice pattern. This might be the app where I most specifically understood how it works, because I created classes called Model and Controller, and I designated the MainActivity class (plus the xml layout) as the view. Totally great idea.
- Learn one or two things at once. In this app, I tried to learn three (MVC, manual dependency injection, and Android camera apps). That will just frustrate you.
- Launch as soon as possible. Especially if you're fed up with the project. After you launch a functional product, if it's just a hobby (and if it's free), you can stop working on it at any time. Before you launch, if you give up, you've just wasted a lot of work. You can always add features later.
- It's amazing the difference between a free hobby app and a paid or corporate app. If Google or whoever launches a thing with a minor flaw, people jump all over it, sometimes nastily. (I know; I've worked on Chrome.) But when you release a free Android app, even if it crashes all the time, people are very friendly, even offering help and support! The feeling I get is "I know you're trying your best. I appreciate it." It's wonderful.
(EDIT: it's unpublished from the market now because it crashed a lot.)
And it was a surprising pain! Some tips that might spare you some pain:
- don't try to use the camera without a preview. It might work, but I feel like some of the developers might have been assuming a preview. (all example usages of the camera, in docs and ApiDemos include a preview.) At any rate, using a preview surface gives you a couple of callbacks that make it easy to manage the camera resources.
- you might get cryptic crashes or ANR's. I don't feel confident that One Photo Every Minute is 100% crash free, even on the Nexus One I was testing it on. This is awful.
Some general thoughts:
- At work, on servers, we use Guice and dependency-inject everything. I tried to do the same here, and it was way overkill. You can, and should, easily bang out a couple thousand lines of code without doing any DI. (this means most of your code won't be unit-testable. I'm okay with that. No, this doesn't scale well.) Maybe I'll get into specific issues later.
- Model-view-controller is a nice pattern. This might be the app where I most specifically understood how it works, because I created classes called Model and Controller, and I designated the MainActivity class (plus the xml layout) as the view. Totally great idea.
- Learn one or two things at once. In this app, I tried to learn three (MVC, manual dependency injection, and Android camera apps). That will just frustrate you.
- Launch as soon as possible. Especially if you're fed up with the project. After you launch a functional product, if it's just a hobby (and if it's free), you can stop working on it at any time. Before you launch, if you give up, you've just wasted a lot of work. You can always add features later.
- It's amazing the difference between a free hobby app and a paid or corporate app. If Google or whoever launches a thing with a minor flaw, people jump all over it, sometimes nastily. (I know; I've worked on Chrome.) But when you release a free Android app, even if it crashes all the time, people are very friendly, even offering help and support! The feeling I get is "I know you're trying your best. I appreciate it." It's wonderful.
Saturday, July 31, 2010
In which I chronicle my descent into vim
Remember when I said, two posts ago, that IDE's were the only sane way to write code? Well, maybe. But I'm starting to think it may be a good idea to learn vim or emacs, like really learn them, because:
- sometimes you just need to edit text that's not code. Maybe more often than code.
- IDE's are still great for autocomplete and stuff, especially in Java. But the higher-level the language, the less good they get. Like python or javascript. When it becomes a cute little syntax checker instead of a big auto-complete auto-import magic-everything Blendtec mixer ("will it refactor? that is the question."), then the overhead starts to kill it. Speaking of which:
- the overhead in IDE's can be killer. Especially on a big project. Especially especially over NX or VNC or Remote Desktop or something.
- I can imagine vim/emacs as a web app (and therefore as the future). I can't imagine Eclipse in the cloud yet.
- sometimes you just need to edit text that's not code. Maybe more often than code.
- IDE's are still great for autocomplete and stuff, especially in Java. But the higher-level the language, the less good they get. Like python or javascript. When it becomes a cute little syntax checker instead of a big auto-complete auto-import magic-everything Blendtec mixer ("will it refactor? that is the question."), then the overhead starts to kill it. Speaking of which:
- the overhead in IDE's can be killer. Especially on a big project. Especially especially over NX or VNC or Remote Desktop or something.
- I can imagine vim/emacs as a web app (and therefore as the future). I can't imagine Eclipse in the cloud yet.
- learning keyboard shortcuts for anything makes you instantly more badass
And given that, I'm going for vim, because I like its style: super minimal, instead of trying to do everything. (if I want it to do that, I'll use an IDE, where ctrl-c is copy and ctrl-s is save.) The dreaded modes are not really that daunting: you're just always in command mode, and sometimes you can press i to blip into insert mode, but only for a minute and then you escape back out into command mode. Text reading is more common than inserting text.
So far, I think my favorite quirk is "." (do whatever you just did, again).
Tuesday, July 27, 2010
Android AudioRecord
AudioRecord is an Android class that lets you record audio and fiddle with it in real time. MediaRecorder is what you want if you'd rather save the audio to a file and deal with it later.
You'll notice that AudioRecord's constructor takes 5 parameters: audioSource, sampleRateInHz, channelConfig, audioFormat, and bufferSizeInBytes. audioSource is reasonable enough; I used MediaRecorder.AudioSource.MIC. For bufferSizeInBytes, you can use the getMinBufferSize() function. (then you might want to multiply the result by 5 or 10 or something.) But the other 3, you kind of have to guess.
I dealt with this for a while, found something that worked on my Nexus One (2.2), launched an app, and then found out that it crashed the Droid (2.1-update1) on startup. So to save you all a similar experience, here's what I know:
44100 hz, AudioFormat.CHANNEL_IN_MONO, and AudioFormat.ENCODING_PCM_16BIT is the one and only configuration guaranteed to work on all phones. The Android Compatibility Test Suite (that phone makers have to run their phones through before they release them) guarantees this (see AudioRecordTest).
Sample rates of 44100, 22050, 16000, 11025, and 8000 hz (and probably others) work on the Nexus One and Droid. Annoyingly, only 8000 hz works on the emulator (2.1-update1), and by "works", I mean "doesn't crash". I haven't tested that it actually records anything useful.
CHANNEL_IN_STEREO works on the Nexus One, but not on the Droid.
This is all correct as of ... about a month ago. Hopefully nothing drastic has changed since then. Make sure you've put the right permission (RECORD_AUDIO) in your AndroidManifest.xml, and good luck recording audio!
Friday, July 23, 2010
Something tells me it's a good idea to have a programming blog.
For one thing, I hear blogs make you rich. Second, it's good discussion at parties. (though this goes without saying.) Third, I'm shooting for tenure, and this really impresses the committee. Fourth, programming blog posts are instant laughs, and a joke a day keeps the doctor away. Speaking of health, Benefit Number Five of programming and blogging is the sweet bulging biceps you get from coding, which in turn helps with Goal Six: aikido mastery. Seventh, a thorough understanding of programming helps you realize and comprehend the oneness of all things, so hopefully we can all learn together here.
I'll not prescribe too much what this blog will be. It'll sort of chronicle my adventures in coding, which right now are making friggin' sweet Web App Frontends with Java and Javascript and a bunch of Google tools at work, and making at least marginally competent Android apps at home.
Let's get the culture wars out of the way too: IDE's are the only goddamn reasonable tools to write code, the higher-level language the better, and git is the stupid content tracker. Oh, and well I'm gonna be rather biased in a Googley direction, although I'll try (try!) to keep that in check. Don't want to get all fanboy about it; it's only the best big software company on the planet.
(and in case you're wondering about perk number 8 of a programming blog: it's the chicks.)
Subscribe to:
Posts (Atom)