- MIT Scientists and the Self-Assembling Chair (Wired) — using turbulence to randomise interactions, and pieces that connect when the random motions align. From the Self-Assembly Lab at MIT.
- Calaos — a free software project (GPLv3) that lets you control and monitor your home.
- Founder Wants to be a Horse Not a Unicorn (Business Insider) — this way of thinking — all or nothing moonshots to maximise shareholder value — has become pervasive dogma in tech. It’s become the only respectable path. Either you’re running a lowly lifestyle business, making ends meet so you can surf all afternoon, or you’re working 17-hour days goring competitors with your $US48MM Series C unicorn horn on your way to billionaire mountain.
- Using Google Cloud Platform for Security Scanning (Google Online Security) — platform vendors competing on the things they can offer for free on the base platform, things which devs and ops used to have to do themselves.
"PaaS" entries
Coding in a cloud-based enterprise
Mapping the future of development by designing for distributed architectures.
With the advent of DevOps and various Platform-as-a-Service (PaaS) environments, many complex business requirements need to be met within a much shorter timeframe. The Internet of Things (IoT) is also changing how established applications and infrastructures are constructed. As a result of these converging trends, the enterprise IT landscape is becoming increasingly distributed, and the industry is starting to map how all the various components — from networking and middleware platforms, to ERP systems and microservices — will come together to create a new development paradigm that exists solely in the cloud.
Applied DevOps and the potential of Docker
The cultural impact within a software engineering organization can be dramatic.
Editor’s note: this post is from Karl Matthias and Sean P. Kane, authors of “Docker Up & Running,” a guide to quickly learn how to use Docker to create packaged images for easy management, testing, and deployment of software.
At the Python Developers Conference in Santa Clara, California, on March 15th, 2013, with no pre-announcement and little fanfare, Solomon Hykes, the founder and CEO of dotCloud, gave a 5-minute lightning talk where he first introduced the world to a brand new tool for Linux called Docker. It was a response to the hardships of shipping software at scale in a fast-paced world, and takes an approach that makes it easy to map organizational processes to the principles of DevOps.
The capabilities of the typical software engineering company have often not kept pace with the quickly evolving expectations of the average technology user. Users today expect fast, reliable systems with continuous improvements, ease of use, and broad integrations. Many in the industry see the principles of DevOps as a giant leap toward building organizations that meet the challenges of delivering high quality software in today’s market. Docker is aimed at these challenges.
Four short links: 23 February 2015
Self-Assembling Chairs, Home Monitoring, Unicorn Horn, and Cloud Security
Working like a startup at IBM
How a small and passionate team used modern techniques to shift a business on a short timeline.
Over the past year, I assisted in creating an application that helped shift a major part of IBM to a software-as-a-service (SaaS) model. I did this with the help of a small but excellent development team that was inspired by the culture and practices of web startups. To be clear, it wasn’t easy – changing how we worked led to frequent friction and conflict – but in the end it worked, and we made a difference.
In mid-2013, the IBM Service Management business and engineering leaders decided to make a big bet on moving our software to the cloud. Traditionally we have sold “on premises” software products. These are software products that a customer buys, downloads, and installs on their own equipment, in their own data centers and facilities. Although we love the on-premises business, we realized that cloud delivery of software is also a great option, and as our customers evolved to a hybrid on-premises / cloud future, we needed to be there to help them.
Four short links: 6 May 2014
On Google, Non-Profit Cleverness, Textbooks in Markdown, and Amazon with Docker
- Letter to Google from CEO of Axel Springer — very well-written and articulate challenge to the positive Google frame: your company will play a leading role in the various areas of our professional and private lives–in the house, in the car, in healthcare, in robotronics. This is a huge opportunity and a no less serious threat.
- Brewster Kahle Talk — notes from a Brewster Kahle talk. Internet Archive using non-profit status to engineer lower costs in surprising ways: accommodation and banking. (via David Weinberger)
- gitbook — code to turn markdown for textbook-style works (including problems and solutions) into PDF, ebook, HTML, etc.
- AWS Elastic Beanstalk for Docker — use Amazon’s deployment tool with Docker images or Dockerfiles.
5 PaaS anti-patterns
Common behavior to watch out for when transitioning to a PaaS
Today I am going to cover 5 ways developers may be on a Platform as a Service (PaaS) but have not really embraced the new platform effectively. If you have done any of these things below while building your application hosted on a PaaS, like OpenShift, Heroku, or Google App Engine, don’t feel bad:
- PaaS is a relatively new concept in the development world and I think some of these patterns are only recently coming to light
- I have seen veteran developers making these mistakes as they move to the new paradigm
One piece of terminology I will use throughout the article is container. When I am using this word I am referring to the piece of the PaaS that hosts the application and does the work. An application can be composed of multiple containers and the PaaS will probably have a method to add your favorite server-side tech to the container. On OpenShift this is called a gear while on Heroku it is called a dyno.
So without further ado, let’s dig in on some of the code smells in the cloud.
5 ways developers win with PaaS
Powering your app with open source and OpenShift
As a software developer, you are no doubt familiar with the process of abstracting away unnecessary detail in code — imagine if that same principle were applied to application hosting. Say hello to Platform as a Service (PaaS), which enables you to host your applications in the cloud without having to worry about the logistics, leaving you to focus on your code. This post will discuss five ways in which PaaS benefits software developers, using the open source OpenShift PaaS by Red Hat as an example.
No More Tedious Config Tasks
Most of us don’t become developers to do system administration, but when you are running your own infrastructure you end up doing exactly that. A PaaS can take that pain away by handling pesky config and important security updates for you. As a bonus, it makes your sys admin happy too by allowing you to provision your own environment for that killer new app idea you want to tinker with, rather than nagging them for root access on a new VM.
On OpenShift, it goes like this: let’s say you decide you want to test an idea for a Java app, using Tomcat and PostgreSQL (yes, we could argue about the merits of those choices, but work with me here). You can spin that up with a one-line terminal command:
rhc app create myawesomeapp tomcat-7 postgresql-9.2 -s
That -s on the end is telling the platform to make the app auto-scaling, which I will elaborate on later; yes, that’s all it takes. RHC (Red Hat Cloud) is just a Ruby Gem wrapping calls to the OpenShift REST API. You could also use the OpenShift web console or an IDE plugin to do this, or call the API directly if that’s how you roll. The key technologies in play here are just plain old Git and SSH — there’s nothing proprietary.
Four short links: 21 August 2013
Approximate Queries, Spreadsheet as Database, China Robot Plans, and Open Source Google App Engine
- blinkdb — The current version of BlinkDB supports a slightly constrained set of SQL-style declarative queries and provides approximate results for standard SQL aggregate queries, specifically queries involving COUNT, AVG, SUM and PERCENTILE and is being extended to support any User-Defined Functions (UDFs). Queries involving these operations can be annotated with either an error bound, or a time constraint, based on which the system selects an appropriate sample to operate on.
- sheetsee.js (github) — Javascript library that makes it easy to use a Google Spreadsheet as the database feeding the tables, charts and maps on a website. Once set up, any changes to the spreadsheet will auto-saved by Google and be live on your site when a visitor refreshes the page. (via Tom Armitage)
- China Plans to Become a Leader in Robotics (Quartz) — The ODCCC too funds high risk research initiatives through the Thousand Talent Project (TTP), a three-year term project with possible extension. The goal of the TTP is to recruit thousands of foreign researchers with strong expertise in hardware and software to help develop innovation in China. There are already more than 100 foreign researchers working in China since 2008, the year TTP started.
- AppScale (GitHub) — open source implementation of Google App Engine.
Tracking Salesforce’s push toward developers
Salesforce's recent investments suggest it's building a developer-centric suite of tools for the cloud.
Have you ever seen Salesforce’s “no software” graphic? It’s the word “software” surrounded by a circle with a red line through it. Here’s a picture of the related (and dancing) “no software” mascot.
Now, if you consider yourself a developer, this is a bit threatening, no? Imagine sitting at a Salesforce event in 2008 in Chicago while Salesforce.com’s CEO, Marc Benioff, swiftly works an entire room of business users into an anti-software frenzy. I was there to learn about Force.com, and I’ll summarize the message I understood four years ago as “Not only can companies benefit from Salesforce.com, they also don’t have to hire developers.”
The message resonated with the audience. Salesforce had been using this approach for a decade: Don’t buy software you have to support, maintain, and hire developers to customize. Use our software-as-a-service (SaaS) instead. The reality behind Salesforce’s trajectory at the time was that it too needed to provide a platform for custom development.
Salesforce’s dilemma: They needed developers
This “no software” message was enough for the vast majority of the small-to-medium-sized business (SMB) market, but to engage with companies at the largest scale, you need APIs and you need to be able to work with developers. At the time, in 2008, Salesforce was making moves toward the developer community. First there was Apex, then there was Force.com.
In 2008, I evaluated Force.com, and while capable, it didn’t strike me as something that would appeal to most developers outside of existing Salesforce customers. Salesforce was aiming at the corporate developers building software atop competing stacks like Oracle. While there were several attempts to sell it as such, it wasn’t a stand-alone product or framework. In my opinion, no developer would assess Force.com and opt to use it as the next development platform.
This 2008 TechCrunch article announcing the arrival of Salesforce’s Developer-as-a-Service (DaaS) platform serves as a reminder of what Salesforce had in mind. They were still moving forward with an anti-software message for the business while continuing to make moves into the developer space. Salesforce built a capable platform. Looking back at Force.com, it felt more like an even more constrained version of Google App Engine. In other words, capable and scalable, but at the time a bit constraining for the general developer population. Don’t get me wrong: Force.com wasn’t a business failure by any measure; they have an impressive client list even today, but what they didn’t achieve was traction and awareness among the developer community. Read more…