I invite you to visit and bookmark my multilingual future tech / innovation / 3D blog. I just started it, and I think you'll like it:
There might be some cross posts, particularly since Python and the Raspberry Pi are used in so many innovations.
Tuesday, January 27, 2015
Sunday, January 25, 2015
Space = rockets
That's what we tend to equate, cause we love them rockets... And, to reach space, it does require a rocket of some sort, at this point. To "explore" space however, at a minimum, only requires a cloudless night, away from the city, and there, with the naked eyes, you can watch the stars, not just a few, but hundreds (some apparently can see upwards of 3000!). Or perhaps you choose a full moon. One can get pretty close even with a 35mm or digital camera with a modest zoom and a tripod.
|The Moon, Sept. 9th 2014, DSLR at 270MM|
The Moon is nice and all, and is great for black and white photography. And there is nothing wrong with that. In fact, there was an interesting talk back in 2012 by Fred Alger, at PyCarolinas: "Sysadmining Python to the Moon". But the blue planet, the earth is a lot more impressive (picture from that talk):
Except that we are back to rockets again? Or are we? Both Fred's talk and mine that year talked about a near space option.
Weather balloons will get you into near space. Space officially starts at 100KM, but one can reach 35-40KM with a latex balloon filled with Helium. Add a parachute, a radar reflector and a payload, and you have your own little private launch and recovery system.
And nowadays, the payload options are numerous. The main thing is that we are no longer limited to sending microcontrollers, but can send actual computers running an operating system, and executing Python code.
An obvious candidate is the Raspberry Pi. Dave Akerman (whom I had mentionned in my talk) has been sending them into space for well over two years now. So when he sent a tweet earlier this month about the Global Space Balloon Challenge, I knew this would be the perfect project for our local Python user group, using a payload with Raspbian Linux and Python on a Raspberry Pi model A+. So many projects are possible within this project.
Hence, Team Near Space (Flying) Circus was born. Let's hope the snake and the penguin will play nice up there...
Tuesday, January 6, 2015
Python documentation standardAfter getting used to putting a blank line before (for symmetry) and after (to separate the method) a class docstring, for what seems like an eternity (it's been in PEP257 for over 10 years I think), I was doing some code review today and was asked about why add a blank line between the class and docstring. So I quoted pep257:
Insert a blank line before and after all docstrings (one-line or multi-line) that document a class -- generally speaking, the class's methods are separated from each other by a single blank line, and the docstring needs to be offset from the first method by a blank line; for symmetry, put a blank line between the class header and the docstring. Docstrings documenting functions or methods generally don't have this requirement, unless the function or method's body is written as a number of blank-line separated sections -- in this case, treat the docstring as another section, and precede it with a blank line.
I have a pep257 tool that highlights exactly that and the wording is still there on this site:
But, it appears that this disappeared from:
I also found this mercurial changeset:
Looks like Guido Van Rossum made the change. Any idea why, beside the fact that as BDFL he can?
Friday, January 2, 2015
PerceptionDe temps a autres, j'entends dire des choses complètement ridicules:
"Ah oui vous utilisez Python. Je connais, c'est un langage de programmation pour écrire des petits scripts, ce n'est pas utilisable à grande échelle.
(En fait il y avait 2 autres points encore plus ridicule dans cette conversation, j'y reviendrai plus tard)
RéalitéUne connaissance travaille chez Bank Of America sur le programme Quartz. Ils sont passes de 0 a 5000 développeurs Python et des millions (plus de 10) de lignes de code en quelques années seulement. On parle de la même échelle pour YouTube. Les projets de 10 millions+ de lignes de code Python sont rares bien sur, mais ce n'est pas du a une raison technique, mais plutôt parce que l'on accomplis beaucoup en peu de lignes de code.
Once upon a time
You would walk in a supermarket, buy hot dogs and hot dog buns. It was a pretty straightforward process. Sausage pack, check. Buns, check.
Then, someone had the idea of making a bun length sausage. Hmm, ok, except that different brand of "bun length" sausages and buns all have different metrics. But hey, that's ok, it was a valiant effort.
More is more
Some time passed, and somebody thought, "hey, let's make a sausage longer than the bun!". Of course, all readers will be quick to point out that there never was a sausage exactly the length of a bun, they were either slightly shorter, or slightly longer. It was just a "more is more" marketing.
You are probably expecting a sausage to appear on the market "shorter than the bun!". And the circle will be complete. But, which one is the better design? Which one innovates? Same answer to both question: the original design for sausage, which dates back to at least the 9th century BC. Anything beyond that is in the presentation (the marketing).
Now, back to technology. Let's take the phone, for example. Clearly, going wireless was an innovation. Going pocketable was an innovation. Touchscreen. Haptics. Innovations. But the same tech, just in a different (bigger and bigger, a.k.a. "more is more" marketing) package, is not innovation (*cough* apple *cough* samsung). In fact, one could say there is a clear regression in that field (phones used to have battery life expressed in weeks, could fit in your pocket, even in jogging shorts, could be dropped multiple times on rock hard surfaces without any problem etc)
You can do it
Before I sign off for the day, do read my post on innovation in general and personal scale innovation from last year.