When they rolled out the latest update to the comment system a month ago, I did my part by upvoting the 'Fix The Comment System' thread.
They addressed some of the show stopping bugs pretty quickly, but it has been 36 days and if you ask me the damn thing is still broken.
The latency for populating threads, as well as the excessive styling, whitespace, borders, and form controls for threads is laughable. How a site with a presumably large budget could conceive such a poor design is beyond me.
But the biggest problem is that I can't open a Digg page with comments on my 1.33 GHz G4 Powerbook. Well, it's not that I can't, it's that I sorely regret it if I do. The fan starts whirring, the beachball kicks in, and my browser is tied up for close to 30 seconds on any well commented page. Seriously, what is going on here?
I've been meaning to sell this laptop for a long time, but maybe I should keep it around for testing my sites and make sure they don't suck as much as Digg.
And to be honest, I'd love the ability to just turn all Digg comments off completely. I do not read Digg for the comments.
Sunday, July 29, 2007
Saturday, July 21, 2007
KISS
Quick follow up to the new Risotto website.
I really like the idea of a simple one-page portfolio. I figure this is kind of like a resume, where longer is not better.
So when building such a simple site, it is advantageous to really think about what you need, or don't need.
Do I need Django for this? No. This is not a dynamic website. But I used Django anyway. I have my dev environment set up where the overhead of starting a new Django project is essentially free, giving me a project structure I am incredibly familiar with, and a few simple features that prove useful even for a site this simple (namely template inheritance). This also allows growth, as I eventually want to write my own blog app and stop using Blogger.
Do I need a CMS for this? No. This is not a multi-page website and I am more than capable editing HTML.
Do I need a Django deployment? No. Configuring a new vhost on one of my mod_python servers, as well as updating the DNS didn't seem smart when the old placeholder page was sitting in a perfectly fine Dreamhost folder. So I opted for a simple deployment:
Where the x's represent the IP of my local Django development server. Wget's `-m` mirrors the dynamic local site and saves the output as static files perfect for hosting on any old shared host.
I think I've managed to do a good job of keeping things simple for this project...
I really like the idea of a simple one-page portfolio. I figure this is kind of like a resume, where longer is not better.
So when building such a simple site, it is advantageous to really think about what you need, or don't need.
Do I need Django for this? No. This is not a dynamic website. But I used Django anyway. I have my dev environment set up where the overhead of starting a new Django project is essentially free, giving me a project structure I am incredibly familiar with, and a few simple features that prove useful even for a site this simple (namely template inheritance). This also allows growth, as I eventually want to write my own blog app and stop using Blogger.
Do I need a CMS for this? No. This is not a multi-page website and I am more than capable editing HTML.
Do I need a Django deployment? No. Configuring a new vhost on one of my mod_python servers, as well as updating the DNS didn't seem smart when the old placeholder page was sitting in a perfectly fine Dreamhost folder. So I opted for a simple deployment:
wget -m http://xx.xx.xxx.xxx:8000/
Where the x's represent the IP of my local Django development server. Wget's `-m` mirrors the dynamic local site and saves the output as static files perfect for hosting on any old shared host.
I think I've managed to do a good job of keeping things simple for this project...
Company Website
I finally put a simple website up for Risotto:
http://risot.to/
I just wanted something clean, simple and to the point. Hopefully this single page meets those requirements.
http://risot.to/
I just wanted something clean, simple and to the point. Hopefully this single page meets those requirements.
Tuesday, July 10, 2007
Build a website in...
Rails started the craze of the 'build a blog in 15 minutes' example and since then there have been many 'me-too' screencasts, tutorials and blog posts.
This is not one of those super-exaggerated demos. This is an actual real-world example of 'build an X in Y minutes':
UntoldGood
Timed, from start to finish, this website took 2.5 hours.
2.5 hours for:
This isn't the most flashy website, but it is exactly to Seth's design spec (he actually came over with legal paper and cut outs and post-its taped to it). It is simple but this is all he needs. It isn't complete. The blog is missing, though we could fake it with the CMS. We talked about a lot of features he wanted, but he gladly accepted my rejection of all but the essential functions for the first cut.
Still, Seth was really happy. His ideas for the site started a mere 12 hours earlier, he called and asked 'what are you doing this afternoon?' a few hours earlier, and here he was with his website up on the Internet. He was making links to his friends' websites when he doesn't know a lick of HTML. He was already honing in on the next set of work for version 2 now that he got his hands on version 1.
I was really happy. I opened a beer and watched Seth fill in the links and tweak the copy through the admin interface. "This is really easy" he actually said out loud. I drank another beer and watched some TV. There were a couple of small tweaks that I made during commercials.
This one was under budget, and more importantly done. "Is that really when you came over?"
3 hours is a magic number in consulting. Nothing happens in less than 3 hours. Even on the easiest projects.
You forget about the overhead of starting anew, or you get sidetracked on a meaningless but tricky and fun challenge programming wise, or you just can't locate those certain docs, or track down that weird javascript bug, or can't remember how to do vertical centering, or scratch your head over an indentation bug, or can't decypher what this old code is actually doing (dang I should rewrite this), etc.
Then ADD kicks in. Reddit calls. I need a drink. New email.
Then damn apache is just not honoring my virtual host directives. Then WTF mod_php breaks mod_python and I can't log into the admin?! Then what is that Postgres password again?
I could go on.
But this one wasn't like that at all.
Conclusions to draw from all of this?
This is not one of those super-exaggerated demos. This is an actual real-world example of 'build an X in Y minutes':
UntoldGood
Timed, from start to finish, this website took 2.5 hours.
2.5 hours for:
- A simple CMS (set page name, and textile content)
- A simple Links application (set link URL, text, and category)
- HTML templates
- CSS
- Deployment
This isn't the most flashy website, but it is exactly to Seth's design spec (he actually came over with legal paper and cut outs and post-its taped to it). It is simple but this is all he needs. It isn't complete. The blog is missing, though we could fake it with the CMS. We talked about a lot of features he wanted, but he gladly accepted my rejection of all but the essential functions for the first cut.
Still, Seth was really happy. His ideas for the site started a mere 12 hours earlier, he called and asked 'what are you doing this afternoon?' a few hours earlier, and here he was with his website up on the Internet. He was making links to his friends' websites when he doesn't know a lick of HTML. He was already honing in on the next set of work for version 2 now that he got his hands on version 1.
I was really happy. I opened a beer and watched Seth fill in the links and tweak the copy through the admin interface. "This is really easy" he actually said out loud. I drank another beer and watched some TV. There were a couple of small tweaks that I made during commercials.
This one was under budget, and more importantly done. "Is that really when you came over?"
3 hours is a magic number in consulting. Nothing happens in less than 3 hours. Even on the easiest projects.
You forget about the overhead of starting anew, or you get sidetracked on a meaningless but tricky and fun challenge programming wise, or you just can't locate those certain docs, or track down that weird javascript bug, or can't remember how to do vertical centering, or scratch your head over an indentation bug, or can't decypher what this old code is actually doing (dang I should rewrite this), etc.
Then ADD kicks in. Reddit calls. I need a drink. New email.
Then damn apache is just not honoring my virtual host directives. Then WTF mod_php breaks mod_python and I can't log into the admin?! Then what is that Postgres password again?
I could go on.
But this one wasn't like that at all.
Conclusions to draw from all of this?
- Django kicks ass; apps are highly reusable and the admin interface provides an amazing shortcut for CRUD, and the clients love it.
- Sitting down next to the client to work is both a great motivator and and easy way to prioritize (what can we do while you are here?).
- Getting your tools, your workflow, and your deployment server as frictionless as possible is incredibly important -- you will know when this has happened and it will feel great.
Saturday, June 30, 2007
Sicko Criticisms?
I Just read Kurt Loder's criticism of Michael Moore's Sicko. I think Loder's argument against Moore is weak.
Moore's thesis in Sicko is that the U.S. system is busted and that there are better alternatives than an employer based for-profit system. To back up this thesis, Moore offers experiential accounts of how the U.S. system fails some people, as well as experiential accounts of how other systems do not suffer the same problems.
To my recollection, Moore never says that we need to adopt Canada's system exactly, nor France's nor Britain's. Moore also doesn't fail to mention that the U.S. system works just fine for a large portion of the population. He is simply offering examples of stark contrast -- like not needing to be employed to be covered, not being denied care to pad a corporation's bottom line, never needing to cut a check at the hospital, and free in-home doctor's visits -- to get his viewers to think 'wow, what if...?'
If I had to wager a guess, I'd bet Dead Meat handles Canada's system in a similar manner. Point out some horror stories of people waiting too long, mention that of course the system isn't totally busted in passing, and then show how the US gets something better in some cases (namely the ability to buy your way into great healthcare). Using Canada's Sicko to debunk Moore's Sicko doesn't make a whole lot of sense.
Really, Loder's primary argument is that socialized health care does not work. He offers good evidence of this, but this has little to do with Moore's filmmaking techniques. I agree with Loder's distrust of the U.S. government to execute such a system well. But Moore's message of disassembling the mega-insurance corporations, not letting people slip through the cracks, and expecting our elected officials to try harder resonates much more with me.
I will concede that Loder's criticism of Moore's Cuba portion is valid. I feel no need to defend Moore for his stunts like this, except that these criticisms seldom consider that Moore has a different prerogative.
This is Moore flexing his entertainer muscle. He could have simply cut a check out of his own pocket to pay for the care his subjects need in the U.S. Boring. Instead he attempts to diffuse 'Socialism' as a dirty word by showing that Cuba is not a totally evil regime deserving of the U.S. embargo, and might even be another country we can study to figure out how to fix our system.
Very questionable in the pure documentarian sense, but entertaining, effective, subversive, and uniquely Moore.
Moore's thesis in Sicko is that the U.S. system is busted and that there are better alternatives than an employer based for-profit system. To back up this thesis, Moore offers experiential accounts of how the U.S. system fails some people, as well as experiential accounts of how other systems do not suffer the same problems.
To my recollection, Moore never says that we need to adopt Canada's system exactly, nor France's nor Britain's. Moore also doesn't fail to mention that the U.S. system works just fine for a large portion of the population. He is simply offering examples of stark contrast -- like not needing to be employed to be covered, not being denied care to pad a corporation's bottom line, never needing to cut a check at the hospital, and free in-home doctor's visits -- to get his viewers to think 'wow, what if...?'
If I had to wager a guess, I'd bet Dead Meat handles Canada's system in a similar manner. Point out some horror stories of people waiting too long, mention that of course the system isn't totally busted in passing, and then show how the US gets something better in some cases (namely the ability to buy your way into great healthcare). Using Canada's Sicko to debunk Moore's Sicko doesn't make a whole lot of sense.
Really, Loder's primary argument is that socialized health care does not work. He offers good evidence of this, but this has little to do with Moore's filmmaking techniques. I agree with Loder's distrust of the U.S. government to execute such a system well. But Moore's message of disassembling the mega-insurance corporations, not letting people slip through the cracks, and expecting our elected officials to try harder resonates much more with me.
I will concede that Loder's criticism of Moore's Cuba portion is valid. I feel no need to defend Moore for his stunts like this, except that these criticisms seldom consider that Moore has a different prerogative.
This is Moore flexing his entertainer muscle. He could have simply cut a check out of his own pocket to pay for the care his subjects need in the U.S. Boring. Instead he attempts to diffuse 'Socialism' as a dirty word by showing that Cuba is not a totally evil regime deserving of the U.S. embargo, and might even be another country we can study to figure out how to fix our system.
Very questionable in the pure documentarian sense, but entertaining, effective, subversive, and uniquely Moore.
Friday, June 29, 2007
Django MySQL with InnoDB Tables
If you are using MySQL and want Django to create InnoDB tables on `syncdb`, use the following in your settings file:
This works on trunk, and isn't documented very well.
DATABASE_ENGINE = 'mysql'
DATABASE_OPTIONS = {"init_command": "SET storage_engine=INNODB"}
This works on trunk, and isn't documented very well.
Calibration
I want 80 column wide <pre> blocks. Going to play with the CSS until this looks right...
There.
12345678901234567890123456789012345678901234567890123456789012345678901234567890
There.
Subscribe to:
Posts (Atom)