The aliens are the bullet points from the source PDF. WTF?
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.
Subscribe to:
Posts (Atom)
