サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
画力アップ
ianbicking.org
Or: The Best Way To Do Something Is To At Least Try We all know the story: you can’t make money on open source. Is it really true? I’m thinking about this now because Mozilla would like to diversify its revenue in the next few years, and one constraint we have is that everything we do is open source. There are dozens (hundreds?) of successful open source projects that have tried to become even jus
I have been part of the Firefox Test Pilot team for several years. I had a long list of things I wanted to build. Some I didn’t personally want to build, but I thought they were interesting ideas. I didn’t get very far through this list at all, and now that Test Pilot is being retired I am unlikely to get to them in the future. Given this I feel I have to move this work out of my head, and publish
Since my last post about leaving Python, my career has shifted further. Earlier this year Mozilla shut down its Labs group. It’s a little hard to tell – I guess we didn’t actually shutter anything, and though it was announced internally it is entirely unclear externally. But Mozilla Labs is definitely shut down. Most of those who were still part of Labs at the end moved to the Mozilla Foundation (
I was listening to a podcast with some people from GitHub and I was struck by Hubot. My understanding of what they are doing: Hubot is a chat bot — in this case it hangs out in Campfire chat rooms, but it could equally be an IRC bot. It started out doing silly things, as bots often do, then started offering up status messages. Eventually it got a command language where you could actually do things
On a couple projects I’ve used GitHub Issues as the primary technique to organize the project, and I’ve generally enjoyed it, but it took some playing around to come up with a process. You, reader, may also like this process, so I will describe it for you. GitHub Issues has a slim set of features: Issues, of course Issues can be assigned Issues belong to zero or one milestone Issues can have any n
This post is long overdue; this isn’t a declaration of intent (any intent was long ago made real), just my reflection about my own path. I left the Python world a long time ago but I never took a chance to say goodbye. While I had moved on from Python years ago, I felt a certain attachment to it well past then, not quite admitting to myself that I wasn’t coming back. When my proposal for PyCon 201
A programming quandry (related to some thoughts I’ve had on locality): The prevailing wisdom says that you should keep your functions small and concise, refactoring and extracting functions as necessary. But this hurts the locality of expectations that I have been thinking about. Consider: function updateUserStatus(user) { if (user.status == "active") { $("<li />").appendTo($("#userlist") .text(us
Javascript objects and classes aren’t hard. This whole “prototype” thing is blamed for too much: prototype-based programming isn’t hard. this is really weird, but prototypes aren’t. What’s prototype-based programming? It just means every object has a “prototype” and when you look up a property on the object it searches the object, then the object’s prototype, then the prototype’s prototype, and so
You’ve reached my homepage on the world wide web. Hello! On the internet I’m a computer programmer. Not on the internet I am also a computer programmer, but I also have a wife and two daughters. I live in Minneapolis, in the Powderhorn Park neighborhood. On the internet I live here; I can’t find a social media home, but I’m trying Mastodon and still use Twitter. I worked at Mozilla for 10 years un
In a recent post on Framework design James Bennett describes as a fundamental dichotomy in framework design "full-stack" vs. "glue". In this case, Django (which James works on) as a full-stack framework, and TurboGears and Pylons as glue frameworks. This is not a good way to describe the differences. Both TurboGears and Pylons have glue. They have taken existing components and put them together. B
{ 2008 12 10 } lxml: an underappreciated web scraping library When people think about web scraping in Python, they usually think BeautifulSoup. That’s okay, but I would encourage you to also consider lxml. First, people think BeautifulSoup is better at parsing broken HTML. This is not correct. lxml parses broken HTML quite nicely. I haven’t done any thorough testing, but at least the BeautifulSoup
So I promised some more technical discussion of App Engine than my last two posts. Here it is: Google App Engine uses a somewhat CGI-like model. That is, a script is run, and it uses stdin/stdout/environ to handle the requests. To avoid the overhead of CGI a process can be reused by defining __main__.main(). But while a process can be reused, it might not be, and of course it might get run on an e
In preparation for my PyCon talk on HTML I thought I’d do a performance comparison of several parsers and document models. The situation is a little complex because there’s different steps in handling HTML: Parse the HTML Parse it into something (a document object) Serialize it Some libraries handle 1, some handle 2, some handle 1, 2, 3, etc. For instance, ElementSoup uses ElementTree as a documen
Dear helpful readers... What is the best practice for handling daemons and server processes? Does anyone know of good documentation on this? Especially considering that otherwise "good" software often is crappy at handling this part? paster serve is, in effect, a little application server. It has a --daemon option and other options. I try to make them nice, but things trip me up. Like, I enter dae
So, I was reading through comments to despam my old posts before archiving them, and came upon this old reply to this old post of mine which was a reply to this much older post. I won’t reply to that post much, because it’s mostly… well, not useful to respond to. But people often talk about the wonders of Open Classes in Ruby. For Python people who aren’t familiar with what that means, you can do:
TurboGears and Pylons are two popular web frameworks; TurboGears hit the scene about a year and a half ago, Pylons started picking up steam maybe six months ago. They are both modern MVC frameworks, targeting a similar style of development. Here's a description of the technical differences: Similarities Both are MVC-style frameworks. Neither is particularly CMS oriented in the framework itself (un
Since I'm thinking about writing a Javascript Logo, I decided I needed a good test framework. I was happy with my hack to use Python's doctest for testing Logo, so I thought I'd try to use doctest style testing in this project too. I haven't started on the Logo part yet, but I did write a Javascript doctest runner. It uses MochiKit, located at http://svn.colorstudy.com/doctestjs/trunk/ -- but more
There are different opinions on the relative power of Ruby and Python. I'm not much more authoritative than other resources (though I'm not less authoritative either; most comparisons between the two languages are flawed). Ultimately I don't believe there are many (any?) places where one language is more "powerful" than the other (and not just in the "they are both Turing complete" sense). This wa
このページを最初にブックマークしてみませんか?
『Ian Bicking: a home page』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く