I was at that talk. Having not done much C since college 6 or 7 years ago and only really starting Python about 3 months ago, it was very approachable and I got a lot out of it. I highly recommend it.
Now, do you think that is the driver personally using square to accept card payments as it's more economical for him to manage that stuff himself rather than relying on the cab company?
That seems likely, but I don't have evidence either way. In one case the transaction came through as what I presume was the driver's name, the other as "SQ *TAXI OF CHICAGO".
Still, the that fact that out of three recent cab rides, the two trips involving credit cards were both paid for using Square is an impressive sign.
As noted by others in this thread, drivers here regularly try to use the "machine is broken" tactic, despite the law. If Square's existence makes taking credit cards sufficiently easier for drivers then cab riders will directly benefit.
Last July I took a taxi in Chicago and the driver was using a Square card reader. I take a few taxis every week in various cities, always paying by credit card (so it can be expensed), and it was the first and only time I've seen a taxi driver using Square.
I asked him about it and he said it was personal and he had not seen any other drivers using one. It's non-sensical and as an earlier poster noted, also a bit of a political issue, since the existing terminals force the driver to pay 6% versus 2.75%, with no ad revenue sharing. I talk to the drivers here in Boston quite often, and they have no choice on the terminals they have in the cars. One would think that if drivers are forced to accept credit cards, they should at least have the option of choosing a vendor.
I've been writing Python for maybe 3 months now and as I started digging into the OO stuff, I commented to a few developers about how it 'felt' a lot like javascript and they nearly took my head off. Is there any material you (or anyone for that matter) can point me to that might help solidify my argument?
2) Python will automatically bind methods when you retrive them from an instance. Unless you explicitly bind a function in JS, the "this" parameter is specified at call time: whatever comes before the dot is used as "this". Ultimately they're both first class objects and the difference to the developer is notation:
3) Attribute lookups in Python behave very similarly to property lookups in Javascript. Python has a modified resolution order for searching for an attribute through its list of parent classes. Javascript will look for an attribute in a series of prototypes (since in JS, an instance's prototype is just an object, so it too can have a prototype). Python is superior here because it supports multiple inheritance, but overall the resolution behaviour is essentially the same.
Can you elaborate? Honestly I think the differences far outweigh the similarities.
One case that comes to mind is how each language implements (what I call) the continuation pattern. Suppose you want to iterate over the vertices of a binary tree. In JavaScript, you would accept a callback parameter which you call with each vertex. In Python, you would yield each vertex to the caller. These are very different styles and lead you in different directions.
It is one of the eventually goals, but Travis has a lot of moving parts due to its distributed nature. We do plan to make in-house installs easier in the future.
It is pretty heavily integrated with Github. And at least last time I checked it was challenging to get it to use private Github projects. I believe the feature is on their roadmap, though.
That IS my setup at work. I've recently discovered mutt and irssi which I use for email and chat, respectively. All development happens in tmux sessions with vim. My dock contains finder, iterm2, chrome and the trashcan. If I could remove finder and the trashcan I would...
On a slightly related topic, I've started investigating writing a console based email client recently in Python using Urwid for curses stuff that's a little less archaic than mutt.
My biggest desire to learn a language like Haskell or Scala would be the total shift in thinking required to grasp the language (the author mentions this). I've started playing with clojure lately and even though I've barely scratched the surface (primarily poking around 4clojure.com) I could already feel my brain twisting in ways I've never experienced before. I firmly believe once you turn that corner and really start to get it, you start seeing and attacking problems in such a different light that there's no going back. The big problem I've had recently is finding the motivation to learn anything outside of work (programming/engineering related at least); once you start getting paid to do something its really hard to do it for free, haha.
This was a really bad comparison/argument for git. Anyone actually trying to decide between the two should just forget everything you've read and start with a different source.
That aside, I've used both over the last 3 years (2 in git; 1 in hg) and although I prefer git, hg is a fantastic tool. I think the largest difference between the 2 is usability. I do believe hg is quite a bit easier to pick up. It does a really good job of, by default, making sure you don't shoot yourself in the foot and also keeps you further away from the 'nitty-gritty'. Git, on the other hand, allows you to do whatever you want and generally makes the assumption you always know what you're doing. The details are not very far down from the surface and it's easy to get yourself in trouble if you don't know what you're doing.
Personally I prefer git because I feel so close to the metal, but there's certainly a perfectly valid argument to choose hg over git.
