I’m surely the last developer using Leopard, but Snow Leopard couldn’t compete with Ubuntu and Lion has more warts than the Wicked Witch of the West.
Anyway, you can’t just install lxml with pip (the preferred way of installing Python libraries) because lxml depends on a recent version of libxml2. If you try, gcc will stop when it encounters missing headers added in later versions of libxml2:
libxml/schematron.h: No such file or directory blah blah blah
Instead, use the fabulous Homebrew to install a newer version of libxml2 and then run pip with that version.
brew install libxml2 pip install lxml --install-option="--with-xml2-config=/usr/local/Cellar/libxml2/2.7.8/bin/xml2-config"
Starting on March 28, most NYTimes.com articles will be available to paying customers only. According to the FAQ, everyone will be able to read articles if they click-through from Facebook, Twitter, or a blog. Here is the exact wording:
Can I still access NYTimes.com articles through Facebook, Twitter, search engines or my blog?
Yes. We encourage links from Facebook, Twitter, search engines, blogs and social media. When you visit NYTimes.com through a link from one of these channels, that article (or video, slide show, etc.) will count toward your monthly limit of 20 free articles, but you will still be able to view it even if you’ve already read your 20 free articles.
I don’t envy the New York Times right now, because implementing the new policy will be difficult. The simplest method of detecting Facebook click-throughs is to check HTTP referrers. That is also the weakest algorithm, because spoofing HTTP referrers is easy. Referrer spoofing wont be limited to geeks either – a small Firefox extension could enable the masses.
This email got past gmail’s spam filters, but don’t reply if you receive it.
Due to the large number of people arriving here from Google, I’m running some analytics to figure out why this still hasn’t been marked as spam. Please help out by letting me know what email address and subject he used to contact you.
from Dr. Ge Haijiao <email@example.com>
date Sun, Feb 13, 2011 at 5:43 AM
hide details 5:43 AM (4 hours ago)
I have a business transaction for you.Reply for details
Disclaimer: Due to time constraints, I am not an active Zeitgeist developer right now. Seif Lotfy is the man.
GNOME Zeitgeist is a file manager application for the GNOME desktop environment. Instead of providing direct access to the hierarchical file system like most file managers, GNOME Zeitgeist mainly classifies files according to metadata. This includes time and date of previous accesses, location of use (using GPS positioning), file type, tagging and more. In addition to local files, GNOME Zeitgeist also organizes web browsing history, email and other data sources.
What’s wrong? Zeitgeist is not a file manager. The GNOME Activity Journal can be used to replace a file manager and do file manager-like things, but Zeitgeist is more than that. Check the official Zeitgeist website for details.
If you are a Linux user, how do you use Zeitgeist?
Crucial infrastructure for small projects
My latest project is a web application, which is currently in closed beta. I will blog about that more in the coming weeks, but today I’d like to discuss my project’s infrastructure. Infrastructure is one of those topics that you usually just learn about from the companies that you work with. I hope that the information here will be useful to individual developers and small startups. It is difficult to know what has to be done when you’ve never been part of a real-world development team before.
My project’s team is made up of three people. For a project of that size, there are three resources that I consider to be absolutely crucial:
- A project wiki – For storing project information like budgets, marketing plans, etc. The wiki should replace most emails between team members. The point of a wiki is to establish one place to look for the latest information, so that you don’t need to search through old email threads to find something.
- A project management site – For creating roadmaps, planning new features, reporting bugs, and assigning work to each team member. If you’re going to ignore everything else I write in this post then just setup a project management site. You wont be able to go back and live without it.
- A code repository (aka version control system) – For keeping track of changes to your codebase. Also useful for storing all of your source code in one central and backed-up location. (Yes, that explanation is slightly simplified, but using a version control system should be a given.)
Depending on the nature of your project, you may also need a build-bot or continuous integration server. I don’t have any experience in that area. However, I hear good things about Jenkins (formerly Hudson),
Chef, and Integrity. (Edit: As Tollef Fog Heen pointed out, Chef is a configuration management tool and not a CI server.)