Raspberry PI 2 – Python controlled circuits Button & LED experiments
RaspberryPI digital clock/counter (Photo credit: Wikipedia)
So the last set of experiments definitely piqued my interest in the Raspberry PI platform and its capabilities to measure, control and otherwise interact with the physical world. In reality though, all I’ve done is play with some cheap hobbyist parts that could be picked up at any electronics shop. Still circling around the true capabilities of the PI, I realize I now need to connect the hardware capabilities to the software for creating a proper controller or event-driven system. Afterall, the hardware is where the “Things” aspect of the “Internet of Things” comes in to play and the software is what potentially reaches out to the “Internet” to connect multiple distributed devices or call out to cloud services for message relay between systems, analytics or additional intelligence.
As with the last article I sifted through the web resources out there to try to find the most relevan ones. The following videos show you how to extend the basic Breadboard/Circuit knowledge with the use of logic gates to do “code-on-chip” types of behaviors where your board/circuit can add a bit more intelligence to its basic input/output capabilities, how to safely extend the basic components with real-world sensors, and how to connect directly to the Raspberry PI as a power source via GPIO ribbon cable to control physical electronics experiments with code:
Read the rest of this entry »
Learning Python
Image via Wikipedia
This month I strongly considered taking a full-time position with Keane IT Services (which was recently acquired by NTT Data). Unfortunately, it turned out that role wasn’t a good fit for where I’m at professionally and the responsibilities I have for my family (but it looks like another opportunity I received might be a better fit). As part of the position, I would have needed to beef up my Python skills since one of their client’s Remote Monitoring systems uses it heavily. Not being sure of which version of Python they use, I followed the advice on the official Python site and started with the latest and greatest – version 3.2 – which represents the future of the language.
While learning, I also wanted to make a short course for my wife, because if I could teach her the basics then it would be the perfect proof that I had a handle on the core of the language. Together we successfully walked through the basics of mathematics, string operations, lists, returning values, running a program and packaging a module. I had done some things in Python before but they were mostly around debugging or updating a small section of someone else’s code (i.e. tweaked a Message consumer here, structured a SOAP call there).
Learning from existing code is definitely always the quickest way to learn for me though. To this end, Dive Into Python 3 is hands down one of the best resources other than the Python documentation or official tutorial itself, since it provides code samples. In honesty what helped me most though, was probably the free course offered by Google, which I essentially simplified and repackaged when teaching my wife at home.
After going through the course and feeling a bit confident, I was ready for my first real Python 3.2 program (other than the typical command-line testing and Hello World app). For this I decided to update the Yahoo! Weather Python SDK from 2.x to 3.x and create a Python 3 module for accessing Yahoo! Weather and wrapping their XML Web Services as JSON for consumption by a client. For the client itself, I could have easily written most of the parsing code (if not everything) in my usual manner of using client-side code (i.e. JavaScript) as much as possible then interacting with external Web Services via a server-side proxy, but just for fun and completeness of doing it all server-side I did it all Python style, including outputting the HTML to display the weather report. That way, you can interact with the “index.py” file directly from the browser as a CGI script within Apache that accepts user input via GET submitted from its form, or, interactively via the URL (the URL hacking took a bit of time to get my head around in Python).
Read the rest of this entry »
The Server-Side Proxy
Image via Wikipedia
The Server Side Proxy… oh how I despise thee.
It’s a technique which we wouldn’t have to utilize at all, were it not for Browser security restrictions (which are admittedly in place for a good reason, to save us from ourselves).
Problem
The Same-origin policy, also known as same-domain limitation.
Reaction
After IE4 and a number of other browsers had vulnerabilities revealed where Cross-Site Scripting (XSS) attacks were exploited to gain access to user data, jeopardize accessibility of, or otherwise vandalize popular Web Services and Web Applications, the Browser vendors got together and decided to lock down their browsers into a “sandbox”.
What is a sandbox you ask? In non-developer speak its just like you can find in public parks, a set of boundaries around a soft and malleable plot of land where you can play safely and fall down as much as you want without hurting yourself (or others). Even if you did decide to go on an all-out rampage, you could only at most hurt other people inside the sandbox. In geek speak, its a security mechanism for separating running programs whereby code is isolated to its own space in memory and/or its own path on the network. This effectively means your client-side code can’t make a request to any URL above its own path, let alone to an external Web Service or application.
Solution
BC$ = Behavior, Content, Money
The goal of the BC$ project is to raise awareness and make changes with respect to the three pillars of information freedom - Behavior (pursuit of interests and passions), Content (sharing/exchanging ideas in various formats), Money (fairness and accessibility) - bringing to light the fact that:
1. We regularly hand over our browser histories, search histories and daily online activities to companies that want our money, or, to benefit from our use of their services with lucrative ad deals or sales of personal information.
2. We create and/or consume interesting content on their services, but we aren't adequately rewarded for our creative efforts or loyalty.
3. We pay money to be connected online (and possibly also over mobile), yet we lose both time and money by allowing companies to market to us with unsolicited advertisements, irrelevant product offers and unfairly structured service pricing plans.