It looks (to me) like people just stopped commenting on blog posts. More and more, I might find some great, very technical post, just to discover it has zero comments; ironically, I'd probably got there through a link on Hacker News or Reddit or G+, where it'd have dozens (if not hundreds) of comments. The original author might or might not know about the conversation; if it's happening on one of the large portals, he'll probably find out because of the traffic surge and its side-effects (db crash, bandwidth bill, etc), but if it's happening in a smaller community he doesn't participate in, he might remain completely oblivious to its existence.
This is a sad anti-pattern, exactly as bad as Disqus; it's just another way of building information silos. It's even more sad to see this model being pushed by the geek community, who should know better. Yes, trackback/pingback and RSS have failed; but there must be a better way to interlink the debate across this bunch of URLs we call "the web".
10 January 2012
04 January 2012
IntelliJ PyCharm 2.0 and Jython 2.2 don't really go together
UPDATE: Dmitry Jemerov from IntelliJ responded, explaining what the situation is. TL;DR: 2.2 is simply too old, other features might come if there is demand. I've amended the post to reflect this.
Let me preface this rant by saying that I've been happily using JetBrains PyCharm for a few months, and it's certainly one of the best Python IDEs out there. The price is ridiculously low and if you're serious about Python, buying PyCharm is one of the best investments you can make. It can be used for free for 30 days, so you really should give it a shot.
This said, if you happen to work with Jython 2.2, you'll probably want to use something else. The claim that Jython is fully supported as a runtime, while literally true,is somehow stretched is only valid for 2.5+.
Let's say you work on Windows, and you have your Jython installed under C:\jython-2.2 (yes, it's damn old, but it's still the most widely-deployed release out there -- just ask IBM and Oracle).
You create a new project in PyCharm, then go to Settings -> Python interpreter, remove the preconfigured CPython runtime, then click on Add and point to yourC:\jython-2.2\jython.bat . Bang, "SDK is not valid". The list of library paths, which supposed to be automatically generated by the IDE picking up the environment configuration, is now empty.
Still, PyCharm should be smart enough to parse arbitrary .py files in specific directories, right? So let's click on Add... to point toC:\jython-2.2\Lib , then OK.
Now let's create a .py file, "from pprint import pprint", the module is recognised; "Run" the script, output is correct, life is good: Jython is indeed supported as a Python runtime.
Ok, let's do some file I/O, "import os"... uh, os is not recognised as a valid module. Same for sys. Apparently, they are somewhat special in Jython and are implemented directly into the main jar, so PyCharm can't see them for autocompletion or any other smart feature. I don't know what else is "special" in Jython 2.2, but I'd rather not have to find out.
Which brings us to the main shortcoming of PyCharm as a Jython IDE: it simply won't recognise or parse any Java jar. This is somewhat surprising, considering how the program is basically a spin-off of IntelliJ IDEA, a Java IDE, and is completely built on Java. In fact, it shares the codebase with the Python Plugin for IDEA. One would think PyCharm would be ideally suited to the task of handling the "Python on Java" mesh that is Jython, but alas that's not the case. A quick search on the IntelliJ forum brings up recent posts stating that full Jython support for autocompletion is simply not on the cards; Jython is supported as a runtime and nothing more. In fact, the Python plugin for IDEAprobably handles a Jython setup better than PyCharm, and that's not going to change any time soon. The main target for PyCharm are clearly Django/web developers, not integrators. UPDATE: see this blog post for more details on the real situation.
This state of things is a bit saddening. I don't know if this is a way for JetBrains to avoid cannibalizing its main cash-cow (IDEA), or simply a commercial oversight; the fact is that we have a product, ideally positioned to completely own a niche, which simply refuses to do so and actually delivers a second-rate experience. I hope JetBrains will re-evaluate their stance at some point, because it's a bit of a shame really.
Let me preface this rant by saying that I've been happily using JetBrains PyCharm for a few months, and it's certainly one of the best Python IDEs out there. The price is ridiculously low and if you're serious about Python, buying PyCharm is one of the best investments you can make. It can be used for free for 30 days, so you really should give it a shot.
This said, if you happen to work with Jython 2.2, you'll probably want to use something else. The claim that Jython is fully supported as a runtime, while literally true,
Let's say you work on Windows, and you have your Jython installed under C:\jython-2.2 (yes, it's damn old, but it's still the most widely-deployed release out there -- just ask IBM and Oracle).
You create a new project in PyCharm, then go to Settings -> Python interpreter, remove the preconfigured CPython runtime, then click on Add and point to your
Still, PyCharm should be smart enough to parse arbitrary .py files in specific directories, right? So let's click on Add... to point to
Now let's create a .py file, "from pprint import pprint", the module is recognised; "Run" the script, output is correct, life is good: Jython is indeed supported as a Python runtime.
Ok, let's do some file I/O, "import os"... uh, os is not recognised as a valid module. Same for sys. Apparently, they are somewhat special in Jython and are implemented directly into the main jar, so PyCharm can't see them for autocompletion or any other smart feature. I don't know what else is "special" in Jython 2.2, but I'd rather not have to find out.
Which brings us to the main shortcoming of PyCharm as a Jython IDE: it simply won't recognise or parse any Java jar. This is somewhat surprising, considering how the program is basically a spin-off of IntelliJ IDEA, a Java IDE, and is completely built on Java. In fact, it shares the codebase with the Python Plugin for IDEA. One would think PyCharm would be ideally suited to the task of handling the "Python on Java" mesh that is Jython, but alas that's not the case. A quick search on the IntelliJ forum brings up recent posts stating that full Jython support for autocompletion is simply not on the cards; Jython is supported as a runtime and nothing more. In fact, the Python plugin for IDEA
This state of things is a bit saddening. I don't know if this is a way for JetBrains to avoid cannibalizing its main cash-cow (IDEA), or simply a commercial oversight; the fact is that we have a product, ideally positioned to completely own a niche, which simply refuses to do so and actually delivers a second-rate experience. I hope JetBrains will re-evaluate their stance at some point, because it's a bit of a shame really.
28 December 2011
The Microsoft Touch Mouse Needs Better Software
I've recently picked up a Microsoft Touch Mouse in post-Christmas sales with a huge discount, and I thought I'd describe my experience.
The mouse itself is a nice (Apple-inspired) concept: a multitouch sensor replacing good ol' mouse buttons and wheel; after enduring several mice with hardware defects, having one (almost) without any mechanical moving parts feels reassuring.
Actual usage is slightly less natural than you'd expect. Scrolling is probably the trickiest activity, since in practice it now depends on friction between your finger and the mouse surface, and you have no mechanical feedback.
Right-clicking is also a bit weird, if you're in the habit of resting your index finger while doing it: the sensor detects "rested index + clicking middle" as a different (void) activity, not as a right-click, so you'll need to actually lift the index as you click with the middle finger, or move all the way and right-click with your index finger.
I believe the two items above are to be blamed for 99% of bad reviews; they break long-standing muscle memory for power users, who are heavy on their scrolling and right-clicking, and give a feel that the mouse will randomly decide what to do rather than respond to actual gestures.
The scrolling speed can be adjusted in the driver properties, reducing awkwardness, but there is no tweak for the right-click problem. And this is where Microsoft really failed: there is no way to easily customize the device.
The driver defines a limited set of gestures that you can turn on or off, but you cannot override their assignment (i.e. what they actually do) nor create new ones. Some of these gestures are quite nice: three-finger swipes will bring up the Windows equivalent of Apple's Expose'; two-finger swipes work like Win+Arrows (probably the best feature in the Windows 7 Aero desktop), thumb swipes perform Back/Forward in a very natural way. Unfortunately there is a long list of other gestures that one would really need (open/close browser tabs, a middle-click replacement, window resizing, etc etc) and there is no way to add them; worse, there is no way to simply remap existing gestures to new commands, which should be dead easy; one can only remap left and right click, which nobody will ever do.
Apparently there is a C#/C++ SDK for the sensor (32bit and 64bit), and some students have already come up with nice improvements (like the one shown in this embedded video), but it's a shame that Microsoft, a software company first and foremost, let down this lovely piece of hardware so badly by not shipping a proper gesture editor or mapper. I really do hope they'll release updated drivers with more features in the near future.
The mouse itself is a nice (Apple-inspired) concept: a multitouch sensor replacing good ol' mouse buttons and wheel; after enduring several mice with hardware defects, having one (almost) without any mechanical moving parts feels reassuring.
Actual usage is slightly less natural than you'd expect. Scrolling is probably the trickiest activity, since in practice it now depends on friction between your finger and the mouse surface, and you have no mechanical feedback.
Right-clicking is also a bit weird, if you're in the habit of resting your index finger while doing it: the sensor detects "rested index + clicking middle" as a different (void) activity, not as a right-click, so you'll need to actually lift the index as you click with the middle finger, or move all the way and right-click with your index finger.
I believe the two items above are to be blamed for 99% of bad reviews; they break long-standing muscle memory for power users, who are heavy on their scrolling and right-clicking, and give a feel that the mouse will randomly decide what to do rather than respond to actual gestures.
The scrolling speed can be adjusted in the driver properties, reducing awkwardness, but there is no tweak for the right-click problem. And this is where Microsoft really failed: there is no way to easily customize the device.
The driver defines a limited set of gestures that you can turn on or off, but you cannot override their assignment (i.e. what they actually do) nor create new ones. Some of these gestures are quite nice: three-finger swipes will bring up the Windows equivalent of Apple's Expose'; two-finger swipes work like Win+Arrows (probably the best feature in the Windows 7 Aero desktop), thumb swipes perform Back/Forward in a very natural way. Unfortunately there is a long list of other gestures that one would really need (open/close browser tabs, a middle-click replacement, window resizing, etc etc) and there is no way to add them; worse, there is no way to simply remap existing gestures to new commands, which should be dead easy; one can only remap left and right click, which nobody will ever do.
21 December 2011
VBScript, PowerShell, Python, IronPython, Jython, or... ?
In my job, more and more I find that we end up building distributed architectures, i.e. multi-server installations where services are routinely spread around 20+ Windows boxes, plus the occasional Unix. These services have specific startup and shutdown sequences and dependencies, so they can't just be set to Automatic startup; we usually provide batch files to manage them, but this is quickly becoming ugly and unreliable as the number of machines go up every year. It's also tricky to test actual service availability -- some are binary-based, some are HTTP based, some are Weblogic services, etc etc etc... So I'm investigating alternatives.
The first, natural choice for me was obviously Python: it does everything I need, it's flexible etc. However, distributing scripts to customers is a bitch; either you compile everything with cx_freeze (crashy) or py2exe (no python 3! no 64bit bundling! party like it was 2004! have fun tracking down which un-redistributable DLL or manifest you need on each release...), or you drop an entire environment and teach the customer what python is -- not ideal.
The traditional "native" approach to these problems in the Windows world is VBScript. It's fairly flexible, doesn't need to be deployed on Windows Win2003+ (yes, we still deal with loads of Win2003 servers), documentation is extensive and there are plenty of resources out there.
The problem with VBScript, apart from the ugly syntax and pseudo-OOP quirkiness, is that it's clearly seen as legacy by Microsoft. Year after year, running scripts becomes more cumbersome, security checks increase and new technologies don't expose the necessary interfaces. Does it make sense, in 2011, to invest time and effort building solutions that are, de-facto, already obsolete?
So we come to PowerShell, Microsoft's "future of scripting", which must be the less intuitive shell I've ever had the pleasure to deal with. I simply can't get my head around the way it deals with input and output; it doesn't seem to have reference assignment, so you have to retrieve an object on every line before you can use it; the syntax seems to combine the worst of Perl and Bash, and it quickly becomes unreadable. Also, deploying it on anything older than Vista has to be done manually and has to be justified to customers.
I honestly can't see a good solution here. I keep looking at IronPython, but its infrastructure baffles me and I wouldn't know where to start redistributing programs (I don't use Visual Studio). It's clearly a second-class citizen in the .Net world, with all that it entails.
Maybe Jython? After all, the products we install will drop JREs absolutely everywhere, so I could leverage that. I'd like to avoid going full-Java if I can, I hate the whole byzantine toolchain and I'm not really up to speed with post-1.4 changes; plus, there's always a degree of customization required in each environment, so I'd like to keep stuff as easily-editable as possible.
Please feel free to drop any suggestions in comments, I could really do with them!
The first, natural choice for me was obviously Python: it does everything I need, it's flexible etc. However, distributing scripts to customers is a bitch; either you compile everything with cx_freeze (crashy) or py2exe (no python 3! no 64bit bundling! party like it was 2004! have fun tracking down which un-redistributable DLL or manifest you need on each release...), or you drop an entire environment and teach the customer what python is -- not ideal.
The traditional "native" approach to these problems in the Windows world is VBScript. It's fairly flexible, doesn't need to be deployed on Windows Win2003+ (yes, we still deal with loads of Win2003 servers), documentation is extensive and there are plenty of resources out there.
The problem with VBScript, apart from the ugly syntax and pseudo-OOP quirkiness, is that it's clearly seen as legacy by Microsoft. Year after year, running scripts becomes more cumbersome, security checks increase and new technologies don't expose the necessary interfaces. Does it make sense, in 2011, to invest time and effort building solutions that are, de-facto, already obsolete?
So we come to PowerShell, Microsoft's "future of scripting", which must be the less intuitive shell I've ever had the pleasure to deal with. I simply can't get my head around the way it deals with input and output; it doesn't seem to have reference assignment, so you have to retrieve an object on every line before you can use it; the syntax seems to combine the worst of Perl and Bash, and it quickly becomes unreadable. Also, deploying it on anything older than Vista has to be done manually and has to be justified to customers.
I honestly can't see a good solution here. I keep looking at IronPython, but its infrastructure baffles me and I wouldn't know where to start redistributing programs (I don't use Visual Studio). It's clearly a second-class citizen in the .Net world, with all that it entails.
Maybe Jython? After all, the products we install will drop JREs absolutely everywhere, so I could leverage that. I'd like to avoid going full-Java if I can, I hate the whole byzantine toolchain and I'm not really up to speed with post-1.4 changes; plus, there's always a degree of customization required in each environment, so I'd like to keep stuff as easily-editable as possible.
Please feel free to drop any suggestions in comments, I could really do with them!
06 December 2011
State of Python 3
I want to start a little side-project, basically a few lines of HTTP automation and mail sending; nothing that some Taco Bell Programming couldn't handle, but I don't particularly like shell scripts and I figured it'd be cleaner in Python.
It's 2011 and One Should Really Use Python 3, right ? The box I'll work on is a brand new Debian Testing where Python 2.x is not even installed, perfect! I'll just grab virtualenv... Waitamminute, "python" doesn't even run, but I'm sure I had installed the python3 package...? Oh, "python3" in Debian doesn't give you /usr/bin/python but rather /usr/bin/python3 !
Thank you, Debian Project, for your consistent inconsistency dealing with anything Python-related. Ok, so a quick run of update-alternatives and that's sorted.
Now I'll
easy_install virtualenv... sorry, easy_install3 virtualenv, of course... oops, syntax error, clearly a Python 2.x package there. Does easy_install discriminate between 2.x and 3.x package? Er, no. Joy.
Whatever, I'll just grab virtualenv.py and drop it in /usr/local/bin, right? cool, works a treat. Activated my virtualenv, let's try again to download a couple of libs... paramiko: syntax error, clearly a 2.x package. funkload: syntax error, again a 2.x package. I know, I'll use pip! ... no difference.
Basically I can choose whether to handle libraries like it was 2001, website after website, setup.py after setup.py; or I can develop like it was 2009, i.e. with python 2.x.
I think for now I'll choose life, and drop python 3.
Subscribe to:
Posts (Atom)