It’s always fun to put your Android or Python programming skills on display. A while back, I figured it’d be cool to try and control my laptop via my Android mobile device. Think about it: remote laptop access including being able to play and pause music, start and stop programming jobs or downloads, etc., all by sending messages from your phone. Neat, huh?
Before you keep on reading, please bear in mind that this is a pet project, still in its early stages—but the basic platform is there. By gluing together some mainstream tools, I was able to setup my Android phone to control my laptop via a Python interpreter.
By the way: the project is open source. You can check out the client code here, and the server code here.
The Remote Laptop Access Tool Belt: Python, Twisted, Django, and Amarok
This project involves the following technologies, some of which you may be familiar with, some of which are quite specific to the task at-hand:
Twisted: an excellent event-driven framework especially crafted for network hackers.
Django: I used v1.4, so you’ll have to adjust the location of some files if you want to run a lower version.
Amarok: a D-BUS (more on this below) manageable media player. This could be subbed out for other such media players (Clementine, VLC, or anything that supports MPRIS) if you know their messaging structures. I chose Amarok because it comes with my KDE distribution by default. Plus, it’s fast and easily configurable.
An Android phone with Python for Android installed (more on this below). The process is pretty straightforward—even for Py3k!
At a high level, we consider our Android phone to be the client and our laptop, the server. I’ll go through this remote access architecture in-depth below, but the basic flow of the project is as follows:
The user types some command into the Python interpreter.
The command is sent to the Django instance.
Django then passes the command along to Twisted.
Twisted then parses the command sends a new command via D-Bus to Amarok.
Amarok interacts with the actual laptop, controlling the playing/pausing of music.
We’ve all been there. You’re working on the API back-end, and you’re happy with how it’s going. You’ve recently completed the minimal viable product (MVP), the tests are all passing, and you’re looking forward to implementing some new features.
Then the boss sends you an email: “By the way, we need to let people log in via Facebook and Google; they shouldn’t have to create an account just for a little site like ours.”
Great. Scope creep strikes again.
The good news is that OAuth 2 has emerged as the industry standard for social and third-party authentication (used by services such as Facebook, Google, etc.) so you can focus on understanding and implementing that standard to support a wide range of social authentication providers.
It’s likely you’re not familiar with OAuth 2; I wasn’t, when this happened to me.
Though many Django Developers might consider it blasphemous, sometimes it is actually necessary to deploy Django applications on Windows/IIS, especially when working with a client that has based its infrastructure around the Windows ecosystem. The “blasphemy” part comes from Django having really been targeted at the Unix environment, relying heavily on features like WSGI, FastCGI, and command-line tooling, all of which are foreign to Windows. Fortunately, Django/IIS compatibility is improving, thanks to the addition of features (which would otherwise be a kludge) on both the Windows and the Python+Django sides of the equation, thereby helping to resolve compatibility issues between these two disparate technical worlds.
As mobile and tablet devices come closer to achieving final world domination, web design and technology is in a race to accommodate the ever-growing number of screen sizes. However, devising tools to meet the challenges of this phenomenon brings a whole new set of problems, with one of the latest buzzwords to emerge being “responsive web”. This is the challenge of making the web work on most, if not all, devices without degrading the user’s experience. Instead of designing content to fit desktop or laptops, information has to be available for mobile phones, tablets or any surface connected to the web. However, this responsive web design evolution has proven to be a difficult and sometimes painful one.
While it can be almost trivial to accommodate textual information, the tricky part comes when we put into consideration content like responsive images, infographics, videos, an so forth, which were once designed with only desktops in mind. This not only brings up the question of displaying the content correctly, but also how the content itself is consumed using different devices. Users on smart phones are different to users on desktops. Things like data plans and processing speed have to be considered as well. Google has started to highlight mobile-friendly sites on its search results, with some speculating that it will lead to a substantial pagerank boost to such sites. Earlier solutions addressed this by deploying mobile-only subdomains (and redirects) but this increased complexity and fell out of fashion quickly. (Not every site has the ability to afford this route.)
This is how we water our plats in last vacation for 10 days, worked perfectly.
Using a fish tank aquarium air pump.
All you have to do is make some hole in air pipe and pass pipe through water bucket. make sure holes in pipe are under water. Then water will get into pipe and air flow will pass water to plant pot.
First of all Phalcon is not like any other php framework because it’s a php extension written in C. Php extension are .so files like extension=phalcon.so
Since it’s a php extension it’s always loaded if the extension is enabled in php.ini file, even with nothing build. And this going to make this perform fast.
The framework have no defined directory structure, so you can build your application in different pattern like multi-module, HMVC etc