- Bitcoin: Understanding and Assessing Potential Opportunities (Slideshare) — VC deck on Bitcoin market and opportunities, long-term and short-term. Interesting lens on the development and gaps.
- Queensland Police Map Crime Scenes with 3D Scanner (ComputerWorld) — can’t wait for the 3D printed merchandise from famous trials.
- Atheer Labs — An immersive 3D display, over a million apps, sub-mm 3D hand interaction, all in 75 grams.
- libcloud — Python library for interacting with many of the popular cloud service providers using a unified API.
ENTRIES TAGGED "API"
jQuery makes it really easy to work with the DOM and other browser APIs. Almost too easy. Having the almighty
$ available to you at all times can lead to an architectural style that I refer to as “jQuery soup.”
A jQuery soup codebase is one where adhoc references to
$ appear everywhere. AJAX calls and DOM manipulations are intermingled alongside application logic and business rules.
$ is essentially mutating a big bag of shared global state. That means that whenever you want to modify or extend that part of the app you need to carefully maintain a large mental model of every DOM interaction in your head. That’s really hard to do, and very much prone to error.
UI dynamics, multitasking, maps, and more
iOS 7 is here and we are all very excited. But, as programmers, this isn’t a time to celebrate. This is a time to be concerned. About what, you ask? API Differences is all I can say. How does iOS 7 affect our apps and what is there for us to learn? The iOS SDK is a huge collection of APIs and many of us won’t have time to play with all of the APIs. So we need to be selective about what APIs we use and how efficiently we plan to use them. In this post, I’m going to briefly tell you about some of the new APIs that you need to keep an eye on in iOS 7.
Additions to iOS 7
These are all the Dynamics APIs that Apple has added to UIKit. Start by learning about the UIDynamicAnimator class and take it from there. That is the key to UI Dynamics.
The Fundamental Interconnectedness of Things
A little over a week ago, I wrote about how the authentication model for an unpublished Tesla REST API was architecturally flawed because it failed to take basic precautions against the sharing of credentials with third-parties common to most REST-based services these days. Since its publication, the main criticism of the article centered around the fact that the API is neither a published API nor has it been advertised as being meant for third-party consumption.
The adding of value to devices and services with or without the knowledge/permission of their creators is an integral part of the Internet of Things. These days, people expect an API around their devices. They will discover any APIs and add value to the device/service—even if the task requires a little reverse engineering work. A responsible creator of a device or service in today’s world defined by the Internet of Things must therefore do the following things—always:
- Give it a public API
- Protect any internal communications so they can’t be reverse engineered
- Protect any public communications so that they don’t put end users at risk when they leverage third-party devices and services
For the most part, people use the Tesla REST API via the iPhone and Android mobile apps. The apps enable you to do any of the following:
- Check on the state of battery charge
- Muck with the climate control
- Muck with the panoramic sunroof
- Identify where the hell your car is and what it’s doing
- Honk the horn
- Open the charge port
- Change a variety of car configuration settings
- More stuff of a similar nature
For the purposes of this article, it’s important to note that there’s nothing in the API that (can? should?) result in an accident if someone malicious were to gain access. Having said that, there is enough here to do some economic damage both in terms of excess electrical usage and forcing excess wear on batteries.
These blinders derail Drew Crawford’s detailed rant on Why mobile web apps are slow. It turns out that “slow for what?” is a key part of the question, as Crawford reveals near the very end:
It may also be true that the browser vendors have optimized their performance as far as they can, at least in the relatively stable fields of HTML parsing and processing, and CSS selectors and formatting. Adding
So how can we optimize mobile web development?
OSCON 2013 Speaker Series
NOTE: If you are interested in attending OSCON to check out Dave’s talk or the many other cool sessions, click over to the OSCON website where you can use the discount code OS13PROG to get 20% off your registration fee.
Since 2009, I’ve been leading the optimization team at AppNexus, a real-time advertising exchange. On this exchange, advertisers participate in real-time auctions to bid on individual ad impressions. The highest bid wins the auction, and that advertiser gets to show an ad. This allows advertisers to carefully target where they advertise—maximizing the effectiveness of their advertising budget—and lets websites maximize their ad revenue.
We do these auctions often (~50 billion a day) and fast (<100 milliseconds). Not surprisingly, this creates a lot of technical challenges. One of those challenges is how to automatically maximize the value advertisers get for their marketing budgets—systematically driving consumer engagement through ad placements on particular websites, times of day, etc.—and we call this process “optimization.” The volume of data is large, and the algorithms and strategies aren’t trivial.
In order to win clients and build our business to the scale we have today, it was crucial that we build a world-class optimization system. But when I started, we didn’t have a scalable tech stack to process the terabytes of data flowing through our systems every day, and we didn't have the team to do any of the required data modeling.
So, we needed to hire great people fast. However, there aren’t many veterans in the advertising optimization space, and because of that, we couldn’t afford to narrow our search to only experts in Java or R or Matlab. In order to give us the largest talent pool possible to recruit from, we had to choose a tech stack that is both powerful and accessible to people with diverse experience and backgrounds. So we chose Python.
Python is easy to learn. We found that people coding in R, Matlab, Java, PHP, and even those who have never programmed before could quickly learn and get up to speed with Python. This opened us up to hiring a tremendous pool of talent who we could train in Python once they joined AppNexus. To top it off, there’s a great community for hiring engineers and the PyData community is full of programmers who specialize in modeling and automation.
Additionally, Python has great libraries for data modeling. It offers great analytical tools for analysts and quants and when combined, Pandas, IPython, and Matplotlib give you a lot of the functionality of Matlab or R. This made it easy to hire and onboard our quants and analysts who were familiar with those technologies. Even better, analysts and quants can share their analysis through the browser with IPython.
Now that we had all of these wonderful employees, we needed a way to cut down the time to get them ramped up and pushing code to production.
First, we wanted to get our analysts and quants looking at and modeling data as soon as possible. We didn’t want them worrying about writing database connector code, or figuring out how to turn a cursor into a data frame. To tackle this, we built a project called Link.
Imagine you have a MySQL database. You don’t want to hardcode all of your connection information because you want to have a different config for different users, or for different environments. Link allows you to define your “environment” in a JSON config file, and then reference it in code as if it is a Python object.
Now, with only three lines of code you have a database connection and a data frame straight from your mysql database. This same methodology works for Vertica, Netezza, Postgres, Sqlite, etc. New “wrappers” can be added to accommodate new technologies, allowing team members to focus on modeling the data, not how to connect to all these weird data sources.
In : from link import lnk
In : my_db = lnk.dbs.my_db
In : df = my_db.select('select * from my_table').as_dataframe()
Int64Index: 325 entries, 0 to 324
id 325 non-null values
user_id 323 non-null values
app_id 325 non-null values
name 325 non-null values
body 325 non-null values
created 324 non-null values
By having the flexibility to easily connect to new data sources and APIs, our quants were able to adapt to the evolving architectures around us, and stay focused on modeling data and creating algorithms.
Second, we wanted to minimize the amount of work it took to take an algorithm from research/prototype phase to full production scale. Luckily, with everyone working in Python, our quants, analysts, and engineers are using the same language and data processing libraries. There was no need to re-implement an R script in Java to get it out across the platform.