While debugging another manifestation of the "wrong library for groovy webtest" bug recently, I found an email thread that makes reference the java_home command (sadly, I can't find an online manual page to link to) to cleanly select a specific version of the JVM under OS X. Here I thought manually pawing through /System/Library/Frameworks to look for versions to set JAVA_HOME to was the "right" way to do it. Learn something new every day.
enjoy,
Charles.
Monday, July 13, 2009
Friday, July 03, 2009
Dealing with DreamHost Server Migration
DreamHost sent me an email telling me that my account had been moved to another server. OK, fine - "what's that mean to me, Al Franken?" They said that it shouldn't affect most sites, but that you'd have to look out for paths in your applications that look like "/home/.something/username".
So, when when on my clients emailed me to say that his WordPress site was giving him an error message that read:
Unable to create directory /home/.spuds/user/domain.com/wp-content/uploads/2009/07 . Is its parent directory writable by the server?
I knew that I had been bitten by this error. OK, how to fix it? I grep'ed the WP PHP files, but couldn't find a path like that. So where was it coming from?
On a hunch, I decided to look at the wp_options table in the WP database and found a row called upload_path, and sure enough, it contained the offending directory. I just removed the ".spuds" portion of the path, as per DH's directions, and it all worked.
So, if you're on DreamHost, and they moved your WordPress blog, and it suddenly stopped working with that error message, try looking through wp_options in your databse. (FYI, DH puts a random string between the wp and the options to prevent collisions with other users in the same database.)
enjoy,
Charles.
So, when when on my clients emailed me to say that his WordPress site was giving him an error message that read:
Unable to create directory /home/.spuds/user/domain.com/wp-content/
I knew that I had been bitten by this error. OK, how to fix it? I grep'ed the WP PHP files, but couldn't find a path like that. So where was it coming from?
On a hunch, I decided to look at the wp_options table in the WP database and found a row called upload_path, and sure enough, it contained the offending directory. I just removed the ".spuds" portion of the path, as per DH's directions, and it all worked.
So, if you're on DreamHost, and they moved your WordPress blog, and it suddenly stopped working with that error message, try looking through wp_options in your databse. (FYI, DH puts a random string between the wp and the options to prevent collisions with other users in the same database.)
enjoy,
Charles.
Tuesday, June 30, 2009
Aliens have taken control of my PowerPoint!
I just cut-and-pasted some text from a PDF into PowerPoint, and this is how it rendered:
The aliens are the bullet points from the source PDF. WTF?
The aliens are the bullet points from the source PDF. WTF?
Friday, June 26, 2009
Little Summary of the Open Source Bridge Conference
It's been about a week since the Open Source Bridge Conference, and here are some brief thoughts about it. I'd summarize it by saying that it's approximately 80% as good as OSCON for nearly one tenth the cost, and it was here in Portland.
Of course, it was smaller than OSCON - a lot smaller. But it had a lot of what I go to OSCON for - talks about cool open-source software. There weren't as many talks, not as many projects, not as many "rock stars", but it's the same basic idea. The exhibitors area made a Soviet-era consumer electronics show look like NES. I felt sorry for them.
As I hinted at, the price (something like $250 for non-early bird) was beyond reasonable - it's cheap, in a good way. At the moment, I'm between clients, so there's no way I could afford over $1000 for OSCON. If I had that kind of money this year, I probably would have blown it on the Java Posse Roundup - maybe next year.
Finally, having it in Portland was crucial for me, especially this year. However, I realized a down side to that: since I'm basically local, at the end of the day, I didn't hang around for social events or the hackers lounge, but I rather went out with friends whom I was staying with in the area. So the fact that it's local sort of limited my participation.
Anyway, it was a great version 1.0, and I look forward to going to OSB again next year. Oh yeah, props out to O'Reilly for being a sponsor of a "competing" conference. That was cool.
Charles.
Of course, it was smaller than OSCON - a lot smaller. But it had a lot of what I go to OSCON for - talks about cool open-source software. There weren't as many talks, not as many projects, not as many "rock stars", but it's the same basic idea. The exhibitors area made a Soviet-era consumer electronics show look like NES. I felt sorry for them.
As I hinted at, the price (something like $250 for non-early bird) was beyond reasonable - it's cheap, in a good way. At the moment, I'm between clients, so there's no way I could afford over $1000 for OSCON. If I had that kind of money this year, I probably would have blown it on the Java Posse Roundup - maybe next year.
Finally, having it in Portland was crucial for me, especially this year. However, I realized a down side to that: since I'm basically local, at the end of the day, I didn't hang around for social events or the hackers lounge, but I rather went out with friends whom I was staying with in the area. So the fact that it's local sort of limited my participation.
Anyway, it was a great version 1.0, and I look forward to going to OSB again next year. Oh yeah, props out to O'Reilly for being a sponsor of a "competing" conference. That was cool.
Charles.
Version control: Autopia vs. off-roading
When I was a kid, it was cool to go to Disneyland and ride the Autopia ride. For those of you unfamiliar with it, you get to "drive" a car along a track. As I recall, you get a gas pedal, and the steering worked for about plus-or-minus a foot off the center-line of the track. It is a far cry from driving a real go-cart let alone a real car on the highway or going off-roading (not that I've ever intentionally been off-roading.) Comparing traditional centralized version control systems to distributed version control systems is a bit like autopia vs. off-roading.
With a centralized version control system (VCS), your options are limited, and to a certain extent that can be a good thing. A critical difference between Autopia and a centralized VCS, is that the VCS actually goes somewhere - your code line continues to move forward and doesn't loop back to the starting point.
A distributed VCS (DVCS) can follow the exact same path that a cetralized VCS provides/requires - just like you could drive a 4x4 along the Autopia track. With a DVCS tool like Mercurial, you can implement policies that end up following the same trajectory as you would with Subversion. You have one "master" repository; everyone checks out from it; everyone commits directly to the central repo; the only branching is officially sanctioned, and it occurs in master repo. And that's fine for a lot of applications. Also, some organizations want to operate on the straight and narrow, which is fine if it works for them.
As I mentioned before, I think Mercurial is very simple to use on that path. But, the blessing or curse or fun or power of a DVCS is that you need not follow that track. You can go off the track. Doing so might be the fastest way to get where you're going. Or, you might end up in the weeds. And, you can drive back onto the main road. Developers can head off in some strange direction in their private repo, share their changes with other repos, bring in changes from other repos, abandon their work, or merge it all back into the designated "main" repo. All the while, they have a real VCS tracking their work and saving it - not just random hacking in a random directory.
If Autopia is where you want to be, more power to you. I wouldn't recommend using a DVCS in that environment. Although I don't go seriously "off-road" in my development, I like to have the option to get a little mud on the tires. And even if I'm "driving on the track" and using Mercurial like a centralized VCS, I like to clone a tree onto my laptop to operate disconnected for an extended period, which is something that's not generally possible with traditional VCSs.
My most "extreme" use of Mercurial to-date has been to mirror a P4 repository that I only have intermittent access to. Hg lets me do all my work without having to get the admin to let me onto the P4 repo from by dyanamic IP address. Before that, I would work for weeks without checking in, which makes me nervous. Due to some ignorance and poor planning, I created a bit of a mess in my hg development repo, but I was able straighten it all out, build a series of mq patches, stage them on another repo, and push them back to the P4 tree.
With a centralized version control system (VCS), your options are limited, and to a certain extent that can be a good thing. A critical difference between Autopia and a centralized VCS, is that the VCS actually goes somewhere - your code line continues to move forward and doesn't loop back to the starting point.
A distributed VCS (DVCS) can follow the exact same path that a cetralized VCS provides/requires - just like you could drive a 4x4 along the Autopia track. With a DVCS tool like Mercurial, you can implement policies that end up following the same trajectory as you would with Subversion. You have one "master" repository; everyone checks out from it; everyone commits directly to the central repo; the only branching is officially sanctioned, and it occurs in master repo. And that's fine for a lot of applications. Also, some organizations want to operate on the straight and narrow, which is fine if it works for them.
As I mentioned before, I think Mercurial is very simple to use on that path. But, the blessing or curse or fun or power of a DVCS is that you need not follow that track. You can go off the track. Doing so might be the fastest way to get where you're going. Or, you might end up in the weeds. And, you can drive back onto the main road. Developers can head off in some strange direction in their private repo, share their changes with other repos, bring in changes from other repos, abandon their work, or merge it all back into the designated "main" repo. All the while, they have a real VCS tracking their work and saving it - not just random hacking in a random directory.
If Autopia is where you want to be, more power to you. I wouldn't recommend using a DVCS in that environment. Although I don't go seriously "off-road" in my development, I like to have the option to get a little mud on the tires. And even if I'm "driving on the track" and using Mercurial like a centralized VCS, I like to clone a tree onto my laptop to operate disconnected for an extended period, which is something that's not generally possible with traditional VCSs.
My most "extreme" use of Mercurial to-date has been to mirror a P4 repository that I only have intermittent access to. Hg lets me do all my work without having to get the admin to let me onto the P4 repo from by dyanamic IP address. Before that, I would work for weeks without checking in, which makes me nervous. Due to some ignorance and poor planning, I created a bit of a mess in my hg development repo, but I was able straighten it all out, build a series of mq patches, stage them on another repo, and push them back to the P4 tree.
Monday, June 01, 2009
404 Errors with Django flatpages
In a Python class I'm teaching, I had the students do the Django tutorial with some added bits. One of the added bits was to add an About page using Django flatpages. A couple of students had problems where they were getting 404 errors even though there was a flat page defined at the /about/ URL.
I had one student zip up his project (including his sqlite database) and send it to me. (One of the other "added bits" was that they had to create portable projects - no hardcoded paths in settings.py.) When I first ran his project, sure enough - 404. I poked around, and everything looked good. Then, I used manage.py loaddata to load my data (including a flat page) into his DB, and it all worked fine. So, it was a data issue, not a project-level mis-configuration.
After reading a comment from another student about this problem, I looked into the database using SQLite Manager, where I could see that the flat page was assigned with site_id #3, not the default #1, and somewhere along the line he had created multiple sites in his DB. I looked in settings.py, and sure enough, SITE_ID referred to site #1, not #3 As noted in the flat pages docs, this needs to match (under some circumstance). Changing that, fixed it all up with the students original data.
If you have been having this problem, I am hopeful that the Google sent you here, and you can see how to fix it.
enjoy,
Charles.
I had one student zip up his project (including his sqlite database) and send it to me. (One of the other "added bits" was that they had to create portable projects - no hardcoded paths in settings.py.) When I first ran his project, sure enough - 404. I poked around, and everything looked good. Then, I used manage.py loaddata to load my data (including a flat page) into his DB, and it all worked fine. So, it was a data issue, not a project-level mis-configuration.
After reading a comment from another student about this problem, I looked into the database using SQLite Manager, where I could see that the flat page was assigned with site_id #3, not the default #1, and somewhere along the line he had created multiple sites in his DB. I looked in settings.py, and sure enough, SITE_ID referred to site #1, not #3 As noted in the flat pages docs, this needs to match (under some circumstance). Changing that, fixed it all up with the students original data.
If you have been having this problem, I am hopeful that the Google sent you here, and you can see how to fix it.
enjoy,
Charles.
Friday, April 10, 2009
How to Get a Software Job w/o Experience.
This is a talk I gave at WOU last week. I also presented it later the same week at Beaver Bar Camp. In an ideal world, I would have delivered the talk at least a few weeks before the deadline for Google Summer of Code applications. :-( OTOH, maybe some students will join some F/OSS projects this summer, and they can nail the application next year.
Slideshare liked it (but I'm not sure what their criteria are): "Your presentation How to Get a Software Job w/o Experience is currently being showcased on the 'Career' page by our editorial team."
enjoy,
Charles.
Slideshare liked it (but I'm not sure what their criteria are): "Your presentation How to Get a Software Job w/o Experience is currently being showcased on the 'Career' page by our editorial team."
enjoy,
Charles.
Tuesday, March 24, 2009
Book: Writing for Scholars
Writing for Scholars: A Practical Guide to Making Sense and Being Heard by Lynn P. Nygaard
ISBN: 9788215013916
Writing for Scholars is a great guide for (aspiring) academic writers. The simplest thing I could say is that it ought to be required reading for anyone in graduate school who will be doing academic writing - e.g., journal articles or a dissertation. In my experience, academic writing was something that a graduate student was expected to either know already or absorb quickly without little or no coaching.
I've read a couple of books on the subject of academic writing, especially in the area of the sciences. Those books focused on a lot of the minutia of presenting and formatting one's work in a journal or similar medium. Ms. Nygaard takes a much larger view of the writing process, and she de-emphasizes (without completely dismissing) the technical minutia, putting it in the later chapters. She begins by talking about how to develop good writing habits, which is applicable to non-academic writers, too. She also explains the academic dialogue and how an academic paper has to fit into and extend that dialogue.
She continues by explaining how to identify your audience, which is also applicable to non-academic writing. Then she gets down to what I would term the core of the writing process: forming your argument and expressing it in standard academic form (abstract, introduction, method, results, discussion). She also explains how and when to use figures and tables.
A couple of topics that I don't recall reading in other books are: feedback (giving and receiving) and presenting a paper at a conference. Again, both of these are subjects which were never taught in my graduate schooling. These are both crucial topics that complete the academic dialogue.
Throughout the book, Ms. Nygaard includes numerous (sometimes humorous) examples drawn from a wide range of academic disciplines. Perhaps I'm just reading it through my own science-tinted glasses, but I'd say the book does lean more towards the "hard" sciences rather than social sciences or liberal arts. However, I would assume that non-science writers would find this book just as useful as the geeks in the world.
If I had to make a minor criticism of this book, I'd say that Ms. Nygaard should include some references to other sources relating to the various topics she addresses. This is a short book (less than 200 pages), and that's a good thing. But, as a short book, it cannot possibly be the end-all and be-all encyclopedia for academic writing. For example, her chapter on figures and tables is a great introduction, but references to authors like Tufte would serve the (novice) reader well.
In conclusion, Writing for Scholars is a great guide to academic writing. It is a must-read for anyone beginning a career that will involve such writing, and even seasoned writers can learn a few things by filling in some gaps that were left over from learning by osmosis.
enjoy,
Charles.
ISBN: 9788215013916
Writing for Scholars is a great guide for (aspiring) academic writers. The simplest thing I could say is that it ought to be required reading for anyone in graduate school who will be doing academic writing - e.g., journal articles or a dissertation. In my experience, academic writing was something that a graduate student was expected to either know already or absorb quickly without little or no coaching.
I've read a couple of books on the subject of academic writing, especially in the area of the sciences. Those books focused on a lot of the minutia of presenting and formatting one's work in a journal or similar medium. Ms. Nygaard takes a much larger view of the writing process, and she de-emphasizes (without completely dismissing) the technical minutia, putting it in the later chapters. She begins by talking about how to develop good writing habits, which is applicable to non-academic writers, too. She also explains the academic dialogue and how an academic paper has to fit into and extend that dialogue.
She continues by explaining how to identify your audience, which is also applicable to non-academic writing. Then she gets down to what I would term the core of the writing process: forming your argument and expressing it in standard academic form (abstract, introduction, method, results, discussion). She also explains how and when to use figures and tables.
A couple of topics that I don't recall reading in other books are: feedback (giving and receiving) and presenting a paper at a conference. Again, both of these are subjects which were never taught in my graduate schooling. These are both crucial topics that complete the academic dialogue.
Throughout the book, Ms. Nygaard includes numerous (sometimes humorous) examples drawn from a wide range of academic disciplines. Perhaps I'm just reading it through my own science-tinted glasses, but I'd say the book does lean more towards the "hard" sciences rather than social sciences or liberal arts. However, I would assume that non-science writers would find this book just as useful as the geeks in the world.
If I had to make a minor criticism of this book, I'd say that Ms. Nygaard should include some references to other sources relating to the various topics she addresses. This is a short book (less than 200 pages), and that's a good thing. But, as a short book, it cannot possibly be the end-all and be-all encyclopedia for academic writing. For example, her chapter on figures and tables is a great introduction, but references to authors like Tufte would serve the (novice) reader well.
In conclusion, Writing for Scholars is a great guide to academic writing. It is a must-read for anyone beginning a career that will involve such writing, and even seasoned writers can learn a few things by filling in some gaps that were left over from learning by osmosis.
enjoy,
Charles.
Wednesday, March 04, 2009
Book: Pro Django
Pro Django by Marty Alchin
ISBN: 978-1-4302-1047-4
Pro Django is an excellent book on Django, but it's not for beginners. The term "Pro" gets thrown around a lot, and it gets applied to things that might better be described with "Dummies." This is the Real Mc Coy - it's serious advanced stuff.
The chapters are centered around nice little chunks of the Django system: Models, Views, Forms, Templates, etc. Each chapter is a nice, self-contained bit of Django knowledge, except for Chapter 2, which is a great survey of advanced Python like meta classes. Most chapters also include an Applied Techniques section which gives some examples of how to apply the material in the chapter.
While reading this book, what struck me was how the chapters seem to pack in a level of detail that you'd typically find only in a comprehensive reference, but yet this book is not a bunch of dry reference material, or worse yet, copies of online manuals. The reader gets serious detailed information, but it almost reads like a fluffy tutorial. It's pretty remarkable.
Something that's unique about this book at this time (Q1 2009) is that it covers the 1.0 version of Django. A bunch of the first books on Django were written against 0.96 or earlier. You'd think there wouldn't be much difference (0.04 versions if you only look at the numbers), but the jump to 1.0 was significant for Django. It's nice to have a book that reflects the 1.0 world.
enjoy,
Charles.
ISBN: 978-1-4302-1047-4
Pro Django is an excellent book on Django, but it's not for beginners. The term "Pro" gets thrown around a lot, and it gets applied to things that might better be described with "Dummies." This is the Real Mc Coy - it's serious advanced stuff.
The chapters are centered around nice little chunks of the Django system: Models, Views, Forms, Templates, etc. Each chapter is a nice, self-contained bit of Django knowledge, except for Chapter 2, which is a great survey of advanced Python like meta classes. Most chapters also include an Applied Techniques section which gives some examples of how to apply the material in the chapter.
While reading this book, what struck me was how the chapters seem to pack in a level of detail that you'd typically find only in a comprehensive reference, but yet this book is not a bunch of dry reference material, or worse yet, copies of online manuals. The reader gets serious detailed information, but it almost reads like a fluffy tutorial. It's pretty remarkable.
Something that's unique about this book at this time (Q1 2009) is that it covers the 1.0 version of Django. A bunch of the first books on Django were written against 0.96 or earlier. You'd think there wouldn't be much difference (0.04 versions if you only look at the numbers), but the jump to 1.0 was significant for Django. It's nice to have a book that reflects the 1.0 world.
enjoy,
Charles.
Monday, March 02, 2009
Does OpenOffice Base suck?
Is it just me, or does OpenOffice Base (the database tool in their suite) suck? Or maybe it just sucks on the Mac? Honestly, I'm not throwing bombs just to be a tool. If I'm doing something wrong, please tell me.
For some time I've been looking for a database tool along the lines of Access, but which runs on the Mac and possibly other platforms. It's not that I'm a big Access fan - I've only used it a time or two, but every now and then, I have a task that cries out to be implemented with a database. Creating a desktop application from scratch using something like Swing and JavaDB/Derby seems like overkill (not too mention, way too much work), but I've always thought that there should be a database tool that's based on Java (cross-platform) and some open-source database (e.g., Derby or SQLite).
On paper, Base is just that tool. I heard somewhere that it's written in Java, and I know that it uses HSQLDB, but can use any JDBC database. Looking through the interface it's got tables, forms, and reports. And OpenOffice runs on Macs, Windows, and Linux. Sounds perfect.
Here's just a short list of the issues I've had:
Charles.
For some time I've been looking for a database tool along the lines of Access, but which runs on the Mac and possibly other platforms. It's not that I'm a big Access fan - I've only used it a time or two, but every now and then, I have a task that cries out to be implemented with a database. Creating a desktop application from scratch using something like Swing and JavaDB/Derby seems like overkill (not too mention, way too much work), but I've always thought that there should be a database tool that's based on Java (cross-platform) and some open-source database (e.g., Derby or SQLite).
On paper, Base is just that tool. I heard somewhere that it's written in Java, and I know that it uses HSQLDB, but can use any JDBC database. Looking through the interface it's got tables, forms, and reports. And OpenOffice runs on Macs, Windows, and Linux. Sounds perfect.
Here's just a short list of the issues I've had:
- The first time I ran it, it crashed before I'd even defined any tables. D'oh!
- Once, the UI locked up (no visible updates but the mouse still worked) while I was trying to add a List Box. I kept trying until it crashed. When it came back, I had a zillion List Boxes in the spot where I was adding them.
- After removing the List Boxes, it crashed again. After restarting, the recovery process restored all those list boxes. I removed them all again, it crashed again, and they were all restored again.
- Eventually, I removed the List Boxes, saved and quit. After restarting, the boxes were finally gone. This marked a new work pattern - save and quit every ~5 minutes. Sometimes, saving alone wasn't enough to prevent work from being lost.
- The replace form control function crashed consistently enough for me to realize it doesn't work. This is a shame because the form wizard creates text boxes by default, which need to be converted. I had to add new controls, wire them up, remove the original text box, and move the new control into place - all while saving frequently.
- It took me forever to get a List Box that wasn't tied to a database table or query - e.g., Gender can only be Male or Female (or Gelded on our farm). To do that, you have to turn off wizard mode.
- There are various UI boogers on the Mac - e.g., list boxes are sometimes not quite tall enough so the text in the box is chopped when the list is not dropped down.
- The documentation that I could find was minimal, at best. I realize that's a common complaint about open-source projects, but for something as big as OpenOffice, I expected more.
Charles.
Subscribe to:
Posts (Atom)
