Building ReSTful APIs with Flask in PyCharm

Quickly make your API accessible in just a few lines of code.

Building APIs can be easier than you think. Say you’ve developed a product or service and would like to provide developer access via a ReSTful API quickly, with minimal effort and overhead. The lightweight Flask Python Web framework lets you easily build extendible APIs fast, without the bloat and ceremony of similar tools. Add to this the comprehensive workflow of a modern integrated development environment like PyCharm and you’ll be up and running posthaste.

We’ll start with installing a few prerequisites and set up our working environment so that testing, debugging, and extending the API can happen without too much hopping around. Afterward, we’ll move on to connecting to our database with SQLAlchemy, a Python SQL toolkit and object-relational mapper. We’ll finish up by creating the ReSTful API with Flask-Restless, a Flask extension that provides the simple generation of ReSTful JSON APIs for database models defined by SQLAlchemy.

Read more…

Comment

What is that upside-down tree doing in my browser?

Start using JavaScript to create dynamic web pages by updating the DOM.

The secret to getting your web pages to do your bidding with code is to use JavaScript to manipulate the Document Object Model, or DOM. The DOM is an upside-down tree-like structure that the browser uses to represent your web page internally, and it’s by getting and setting values in the DOM that you can modify your web page in response to users doing things like clicking a button, moving the mouse, or dragging an element around.

Getting started with the DOM is easy once you understand how the browser translates your HTML into this internal structure made of objects. Once these objects are created, then you can manipulate them using a wide variety of properties and methods, to change the content of an element, to add a style to an element, or even remove an element from the page completely.

Read more…

Comment: 1

Who holds your keys?

DRM makes a mash of security and privacy.

Put your books, movies, and music on a gleaming shelf. Close the door to keep the dust off. Lock the door, so no one can take it, and hand me the key. I’ll let you have the key when you need it if you promise not to share these with anyone else.

I might keep track of when you borrow the keys, and what you check in and out. You understand, of course, that it’s just data I need to collect and aggregate to keep my costs down, right? I wouldn’t want to have to charge you very much for my key-keeping service.

It’s the Deal of the Century!

Or, at least, it will be if some kinds of content publishers and distributors get their way. Terrified by the sudden collapse in the cost of duplication and distribution, locking everyone’s shelves down seems like the only way to maintain their balance (sheets). Worse, products from beyond publishing are appearing with the new key-management practices built in, including cars, coffee, and of course printer cartridges. Read more…

Comment

Just fork it

Making forking the norm

Brian Kardell (вкαя∂εℓℓ)tweeted:

Kip Hamptonreplied:

Free and Open Source software licenses make forking legal. Git makes forking easy. GitHub makes it easy to fork sociably. Can we just make this normal?

The most visible recent fork – LibreSSL‘s blunt forking of OpenSSL – was widely reported as conflict. It’s certainly not a polite break, but the OpenSSL’s Apache-style license means it’s legal.

Meanwhile, in a reminder that specifications can fork too, Ian Hickson put his objections to the W3C forking a WHATWG spec on www-archive to make sure his complaints of plagiarism would be part of the permanent record. WHATWG specs are licensed CC0, so once again, it’s legal.

It seems to be a common pattern to want to grant rights, but only want other people to use those rights if they acknowledge our control. (I sometimes have similar tendencies, granted.) We hope that people will contribute to our works while recognizing our power and our ownership over those works. Even the fact that we have to choose licenses at the start of a project gives us a sense of ownership and control, often hiding the (excellent) lack of control that comes once those licenses are applied.

Read more…

Comments: 3

5 ways to improve battery life in your app

Tips and tricks to squeeze the most out of your mobile UI

mobile_html5 Editor’s Note: Mobile HTML5 is a book by front-end engineer and frequent speaker Estelle Weyl. It is packed with hands-on examples to make you a stronger web developer–including best practices for SVG, Canvas, and CSS3 tailored to fit mobile devices. In the excerpt below, Estelle walks you through five easy things you can do to improve battery life in your mobile web apps. As throughout the book, the tips she provides come from her own real-life experience with these technologies.

Unlike desktop computers that are tethered to the wall at all times, and even laptop computers that are generally used by stationary users, mobile users do not recharge their devices throughout the day. Mobile users expect their devices to last, at a minimum, 24 hours between recharging.

Your users do realize that calls and GPS usage consume battery power. However, if they think they’re just using their browser to surf the Web, they don’t consider that different websites will drain their battery faster than other sites. It is our job, as developers, to manage the power consumption of our code. Read more…

Comments: 2

Can we extend the web cleanly?

The DOM and human nature create some challenges

“Design by Committee” is rarely a compliment. Can the Web shift away from that model, retaining some order without falling into troublesome chaos?

The Manifesto

Part of the excitement around the Extensible Web Manifesto was that it wanted to move the Web to more of an evolutionary model:

We aim to tighten the feedback loop between the editors of web standards and web developers.

Today, most new features require months or years of standardization, followed by careful implementation by browser vendors, only then followed by developer feedback and iteration. We prefer to enable feature development and iteration in JavaScript, followed by implementation in browsers and standardization.

Read more…

Comment