Vlad deploy file

Vlad comes with turnkey deployment for rails with apache and mongrel. We’re using merb, so we’ve got to make a few changes. Under config/deploy.rb go ahead and throw something similar to this in:

require 'vlad'

set :application, "applicationname"
set :domain, "yourserver.com"
set :deploy_to, "/path/to/deploy"
set :repository, 'git://github.com/kneath/greed.git'

namespace :vlad do
  ##
  # Merb app server

  set :merb_address,       "127.0.0.1"
  set :merb_clean,         false
  set :merb_command,       'merb'
  set :merb_conf,          nil
  set :merb_extra_config,  nil
  set :merb_environment,   "production"
  set :merb_group,         nil
  set :merb_port,          4000
  set :merb_prefix,        nil
  set :merb_servers,       1
  set :merb_user,          nil

  desc "Prepares application servers for deployment. merb
configuration is set via the merb_* variables.".cleanup

  remote_task :setup_app, :roles => :app do
    "rake"
  end

  def merb(cmd) # :nodoc:
    "cd #{current_path} && #{merb_command} -p #{merb_port} -c #{merb_servers} -e #{merb_environment} #{cmd}"
  end

  desc "Restart the app servers"

  remote_task :start_app, :roles => :app do
    run merb('')
  end

  remote_task :start_app => :stop_app

  desc "Stop the app servers"

  remote_task :stop_app, :roles => :app do
    run merb("-K all")
  end

  remote_task :migrate_merb, :roles => :db do
    run "cd #{current_release}; rake db:migrate MERB_ENV=#{merb_environment}"
  end

  task :update do
    run "cp #{shared_path}/database.yml #{current_path}/config/database.yml"
  end
end

task :deploy => ["vlad:update", "vlad:migrate_merb", "vlad:start_app"]

(I apologize for no credit given to the author of this, but it was in a pastie I found via ma.gnolia.com and I don’t even know where it is anymore)

Setup the server

Go ahead and run rake vlad:setup and make sure all your ssh workings are going good. It should create a /path/to/deploy/shared folder. Inside of that folder, go ahead and throw down your database.yml file with production passwords in it (You aren’t keeping passwords in your source control are you?).

After that, your server should be all set up!

Gitting set up

Vlad

Got Vlad 1.2+? Git submodule is already installed. You just need to edit your rake file and change the vlad require to something like this:

begin
  require 'vlad'
  Vlad.load :scm => "git"
rescue LoadError
  # do nothing
end

Then in your deploy.rb change your repository location to your git url:

set :repository, 'git://github.com/kneath/greed.git'

The Server

Your server must have git installed in order to deploy from a git repository. Some might think a simple sudo apt-get install git-core would do the trick. Well, almost — you’ll run into the following error if you do that:

fatal: You must specify an archive format

Reason for this: apt-get install git-core installs a 1.4x version of git on your Ubuntu machine, and apparently a default for git archive was added in a later version. Solution: install from source. Go to a temporary source folder and run the following commands:

sudo apt-get remove git-core
wget http://kernel.org/pub/software/scm/git/git-1.5.5.1.tar.bz2
sudo apt-get build-dep git-core
tar xjf git-1.5.5.1.tar.bz2
cd git-1.5.5.1/
./configure
make
sudo make install

All might not be well with those commands though. If you hit something like:

SUBDIR git-gui
MSGFMT    po/de.msg make[1]: *** [po/de.msg] Error 127

You’ll need to install gettext (totally makes sense, right?). sudo apt-get install gettext and then start the previous sequence of commands where you left off.

Deploy

After this, everything worked just fine for me. rake deploy and vlad should update your code, run the migrations, and start up your servers.

Advertising available now

Starting today you can go ahead and order some ads on Warpspire, or if gaming is your thing get some Total Spore ads. This is the first time I’ve ever tried the whole private ads thing, so it’s very much an experiment right now. However, I do want to make it clear that I’m going to do my best to keep the ads relevant to the sites’ respective audiences.

The only thing about private ads is that you’ve got to manage them yourself. And pretty much all ad serving software sucks.

Greed

A while (long while) ago I teamed up with Josh Pigford to build an ad serving application. Things didn’t quite work out, mostly because my own goals were higher than my free time. Well, my free time came back and I kicked down my goals a few meters on the goal post. What came out is Greed.

Greed is a simple ad serving web application written in merb. I’ve never written an application in merb before, so I decided to try it out. Greed is also open source, so fork it, hack it, and use it! I’ll try and post up my thoughts on merb in the next few weeks.

Design is a tricky thing. There’s no one right way to do something — it’s a mix of style, aesthetics, and culture. This means that you can solve any design problem a dozen different ways and still come up with something that is interpreted as a success by your client. It can be easy to fall into a design rut, always falling back to your same old tricks. People encourage you by complimenting the work, but deep down sometimes you might wonder if you could have done something better.

That’s why I think design exercises are an important factor of any designer’s career. Every now and then you need to force yourself to solve a problem differently — it’ll force you to branch out and look for new tools and techniques. It’ll force your brain into a new line of thinking and you might even find a new style of design that you prefer. When I look back on my personal projects’ designs, I find that I’ve almost always forced myself into a design exercise from the beginning. The rewards have been monumental personally, so I thought I might work through some of my past work and how I worked design exercises into them.

Examples from Warpspire’s past

Version 3, circa Summer 2004

Exercise: Work with texture to create an appearance of aging.

Solution: This site came out just before Cameron Moll’s Wicked Worn series (or at least, before I had read it). However, I wanted to design something that was notably non-digital-ly. Forcing myself into this style made me look for new approaches to designing, and two great things came of this: the discovery of the incredible diversity of free Photoshop brushes, and the use of photographs/scans in nonstandard ways.

What I mean by that last point is using a photograph for something other than a picture in the page. Creating the envelope in the upper left was incredibly challenging to me at the time, and the only way I was able to reliably recreate it was to use a photograph of an envelope as a stencil of sorts.

Version 4, circa Winter 2005

Exercise: Use color and create something notably non-bloggy.

Solution: This design of Warpspire marked the first design I had created that used any kind of bold or vivid colors; my past designs had always relied on muted or monochromatic color schemes. Forcing myself to work with color ended up in me throwing out nearly a dozen comps, but it was invaluable experience — by the end of it I felt infinitely more comfortable using color in my design.

Version 5, circa Summer 2007

Exercise: Highlight a diverse collection of content on the homepage while dividing opinion from tutorial-type content.

Solution: Forcing myself to let the content do the designing was really tricky. I strayed away from any unnecessary visual clutter, and couldn’t fall back to cheesy ornamentals throughout the site. I think the single largest benefit of this design style was learning to use stock images better. Even adding a mediocre stock image to a design can make the end result visually stunning.

Conclusion

I think the idea of assigning yourself design exercises is a great idea. If you just design with all the tools you have, your designs will soon get stale and you won’t be adding any new tools to your toolbox. By forcing yourself to solve a problem in a different way it forces you to break your normal thinking pattern and explore. It keeps your creative juices flowing and can force you to design in a style you usually wouldn’t turn to.

I actually do the same technique with my programming — every now and then I learn a new language. Pretty much any problem can be solved with the language of your choice, but it’s a good idea to force yourself into new uncomfortable languages just to broaden your knowledge base.

Well I was oh so wrong. Documenting your own code is critical to future maintenance. It’s been almost a year since I launched the rewrite of Poetry with meaning and it’s become incredibly frustrating maintaining the site. I realized the reason for this is lack of documentation and code testing (more on this later). Coming back to 2,000 lines of code without looking at it for 4 or 5 months is just painful. The problem with the code base is that I was taking too much time commenting the code — and no time documenting it.

Let’s take an example of some commented but not documented code:

# clean the filename
stripped_location = @file_location.gsub(/(.+)\.(.+)/, '\1')
stripped_location = @options[:redo] ? stripped_location.gsub(/(.+)_original/, '\1') : stripped_location

This code doesn’t really tell me anything. Cleans the filename? Coming back to this code months after it was written doesn’t tell me a thing.

What I should have been doing is documenting the code. Documentation to me answers the “what does this do?” question. Here’s an example of some code in progress:

module Overseer
  module Backup
    # Creates a backup for one mysql database. The resulting export will be 
    # gzipped and named with the date first and then the databse name
    #
    # Usage:
    #   Overseer::Backup::Mysql.new(:username => "webdb", :password => "ultimatetest", :host => "mysql.example.com", :database => "pwm_production")
    #   For database called "pwm_production" backed up on April 7, 2008 , the final name will be: 2008.04.07.pwm_production.sql.gz
    #
    # Options:
    # * :username - database username
    # * :password - database password
    # * :host (optional) - the database host name
    # * :database - the name of the database
    class Mysql

      attr_accessor :username, :password, :host, :database

      def initialize(options = {})
        @username = options[:username]
        @password = options[:password]
        @host = options[:host].nil? ? "localhost" : options[:host]
        @database = options[:database]
      end

    end
  end
end

I haven’t even really written anything useful yet — but by writing the documentation I’ll know what I was doing a week from today instead of just blindly looking at the code. My documentation tells me how to use the code, not what the code does.

Documenting your code also forces you to really think the functionality through. It makes you think about the architecture of your code before you write it and forces you to think about how it will be used instead of how it was written. It all comes back to the idea that code is written for humans, not machines — so why not start with writing your code 100% human style? (in text!)

The question that struck me in particular came when someone was badgering him at around what size site would you encounter problems scaling Rails. His response was something along the lines of: “No offense, but you won’t ever build a site popular enough to worry about it.” And it’s damn true.

Who cares if your framework can scale if it’s never going to be big enough to worry about? The truth is that almost all web ventures never become big enough to even need a separate database server, let alone a farm of memcached servers, file servers, and enough computing power to plan a trip to Orion. That doesn’t mean they won’t become profitable. You can be extremely profitable with relatively low traffic.

So don’t worry about scaling — scaling is for nerds. By the time you hit pain points, you can bring in someone who really knows what they’re doing. Most importantly, by the time you hit pain points, you should be profitable enough to not worry about bringing in someone who knows what they’re doing.

And no, just because your site goes down for an hour while on the home page of digg.com doesn’t mean that you need to worry about scaling.

More info on that previous link soon :)

But that didn’t stop him from preaching (all comments are disabled and Arron does not respond to email) that you shouldn’t use the technology. Quite honestly, it pissed me off. I sent an email to Arron shortly after reading his post on Thursday, and Arron seemed fit to ignore my email completely.

Here is the letter I sent to him:

Arron,

While I appreciate your intrigue about Flex, I feel like you’re unfairly damning a technology for all the wrong reasons. As per your technical argument, you’re probably right. However that comes with the caveat that JAWS can rarely navigate the majority of the HTML web as it sits today with any sort of ease. It’s no lie to anyone who’s tried to legitimately use screen readers that the technology is highly divisive and non-functional (different readers render differently, function differently, and support different aspects by default).

The sad and unfortunate fact is that anyone who wants a truly accessible site must work very hard, testing and using various screen readers throughout development. (no free lunch indeed). Using standards & best practices only gets us half-way there.

Suggesting that Flex should not be used (”However, until that happens, I can not recommend Adobe Flex.”) is like saying we shouldn’t move forward with HD programming because some people still have SD TV sets. Flex is a revolutionary technology that redefines the rules of what we’re capable of delivering over the web. It can be accessible, and even more so than HTML ever could if you have the desire (you could script your own narrative to guide visually disabled through the form process, accepting voice input and encoding to textual input to the form if you felt the need).

At the end of the day, if you’re looking to deliver a site targeted at visually impaired people, Flex is almost certainly not your choice. The same way social security benefits advertisements will continue to be broadcast in high-contrast SD programming on TV.

But is that reason to not use a technology?

The summary of the above is twofold:

• Even HTML is not accessible by default. You must work very hard to make a fully accessible website using HTML, CSS and (should you dare) Javascript.
• Flex doesn’t really need to be accessible. That’s not the target of the technology.

Much talk and little action is done on the web in terms of “accessibility” and making sites available to the visually impaired. I encourage anyone who has never used JAWS to go ahead and use it on your own site. Then I suggest you try a couple other competing screen reading solutions. I think you’ll find that it’s kind of a crap shoot. Navigating most “accessible” and semantic web sites is maddening at best. Most of the time it feels as though someone’s asking you to read War & Peace without any paragraphs or headings. Sure, the information’s there — but it’s realistically inaccessible.

My point being: accessibility is not something a technology offers. It’s something that a technology can support (and indeed, Flex supports accessibility just fine) — but it’s not something a technology gives you for free.

Unfortunately I believe that Arron has done his damage to the web community and turned thousands away from an amazing technology simply because he doesn’t personally like it. Undoubtedly, Arron’s response will be: “show me.” My response to that is: Why? You’re persecuting a community without cause. Give me proof Flex is not accessible. All in all, I just think it’s sad — and I hope that anyone reading this won’t throw Flex out because it’s “inaccessible.”

The Basics

The core of all of these effects is a simple sequence of events:

1. The effect function is called on an element (i.e. new Effect.Fade(’myid’))
2. The effect function sets a number of initial styles on the element
3. The effect function then defines an update function that modifies CSS properties of the element in reference to a point from 0 to 1
4. This update function is called repeatedly for a set duration of time passing in the reference point each time
5. A cleanup function is called to re-set some of the original styles, and do the final dirty work.

Defining styles

This step is crucial in any effect. In order for some visual effects to be pulled off, certain CSS properties must be set on the element before anything can happen. The most common styles that are modified during this startup time are the overflow and position properties. This allows us to use CSS properties like width, height, left and top to make the element expand, contract, and disappear out of bounds.

Update function

This function is the most important, and also the simplest part of the javascript effect. It modifies one or more of the element’s CSS properties an incremental amount, in relation to an internal reference point (going from 0 to 1). The easiest example of this is opacity. If we imagine that we are going to repeatedly call this function and pass in the reference value, you could easily change the opacity from 100% to 0% by setting the opacity equal to the reference value multiplied by 100%.

Calling the update function

This is the most interesting part of the javascript effects to me. The update function is called is by setting a timer using setTimeout() every so often (40ms is a good interval to start out with). This update function is called for a set duration of time (500ms, or half a second is a typical duration). While this is going on, an internal reference point (mentioned above) is set to a new value each time the update function is called. The javascript uses a formula to generate this reference value much like this: time spent / total duration = counter.

… except there’s one little catch: linear effects feel very unnatural and robotic to the human eye. This is where I get all geeky about the relation between math and design and how everything ties back into math sooner or later (yes, I’m really that big of a nerd). So - if we can’t use a simple linear timeline, what do we use? It turns out that a Sinusoidal patterns work beautifully. This is the equation that the majority of the effects in Scriptaculous and moo.fx use, but they also offer several others: linear, cubic, circular, flicker, wobble, and pulse.

Here are examples of each of these functions using a simple timeline and colored square (to demonstrate the timeline’s effect on a sample opacity effect) over a 2 second period.

Sinusodial

start sinusodial timeline

Linear

Start linear timeline

Cubic

Start cubic timeline

Circular

Start circular timeline

Flicker

Start flicker

Wobble

Start wobble timeline

Bonus! Start all effects simultaneously

Try mixing up these different timelines in your next javascript effects — it’s a great (and easy!) way to make your app feel just a little different than everything else out there.

Cleanup function

The last part of the process is a very simple step that just cleans up any styles that the effect created that you don’t want lying around. If you happen to set a style in the initialization, it’s usually a good idea to undo that style at the end of the effect.

This is also the time you can apply any finisher properties. For elements that are fading out, or zooming out of view — you’ll probably want to be setting display:none; so they are removed from the layout flow.

Conclusion

Once you get a good grip on how Javascript effects work at their core, you’ll soon realize that they’re not so nasty and complex. The hardest part is the math — and most computer geeks I know are pretty good at math. Play around with trying to create your own effects.

Challenge

If you’d like to challenge yourself, try and use your framework of choice (Prototype, MooTools, YUI, jQuery) and build a javascript effect that moves an element in an elliptical path. Hint: You might try absolutely positioning the element inside of a relatively positioned bounding box.

Estimation is a tricky thing: if the answer were easy to come up with, your client/manager/co-worker probably wouldn’t be asking you. As vague as the answer can be, it’s probably the most important thing you’ll ever do in a project. It determines the budget and timeline you’ll have for the project and ultimately create a baseline for measuring success. As such, it’s vital that you exercise and refine this skill as much as possible.

Keep track of progress

The most fundamental step toward accurate estimations is keeping track of your progress. This is easiest in small compartmentalized activities. Next time you sit down to chop out the HTML/CSS/JS of a project’s master template, time how long it takes you to do it.

The second step is to keep track of your co-worker’s progress. As a projects get bigger, teams get bigger, and soon your estimation skills must include estimations of other developer’s time. Keep track of their progress in multiples of your time.

All hours are not equal

Productivity is a tricky thing, and almost impossible to account for. As developers, we know that sometimes you seem to get dozens of hours worth of work done in a day, while others it feels like you’ve accomplished nothing. Here’s a few oddities I’ve learned:

• The longer the project schedule is, the less productive hours become. A three day long project will be much more efficient than a three month long project.
• If you are implementing other people’s code (third party apps, existing custom framework, etc), productivity will be hampered by at least a factor of two. Writing new, clean code is far more productive (it’s more enjoyable to fix your own mistakes than someone else’s).
• Each junior developer you add to a project reduces the efficiency of the senior developer by at least a factor of two.
• Angry/nasty clients will severely hamper the morale (and thus productivity) of the team. Conversely, happy, thankful clients will increase productivity. Account for the attitude of your client in estimations.

Duration versus hours

One of the smaller lessons I’ve learned is that sometimes the determining factor in an estimation is duration, not hours. Hours can be made up in weekends, longer days, and additional developers. However, some activities will take the same duration of time no matter how many hours your throw at it.

A good example of this is bug fixing. Bug fixing in my experience is most usually a duration-based estimation, not an hours-based estimation. Keep in mind when I say bug fixing, I mean the portion of a project’s time for bug fixing — not necessarily fixing specific bugs (which is an hours-based estimation).

How long will it take?

Ultimately the final answer for your estimation will come down to two different values. Hours/cost and duration. How you communicate that value is almost as important as the estimation process itself. Claiming something will take fourteen days is dramatically different than claiming something will take two weeks. Here’s a nifty little chart stolen from The Pragmatic Programmer.

Best case, worst case, target

Another highly effective tool in estimation is to really develop three numbers: one for the best case scenario, one for the worst case scenario, and one with the scenario you feel is most likely to be true. This is important because throughout projects, “unknown unknowns” pop up all of the time. Maybe the filesystem in your subversion server just crashed and you have no source control for a week. Maybe the client got a hold put on their budget and development needs to be a paused for a week. You just never know — and the only way to account for these is by guessing. You minimize the risk of that guess by giving different scenarios.

Your estimation is wrong

Alright, so you’ve figured out the baseline parameters, developed a model, and calculated an estimation. You’re just about to hit Send and fire it off to your boss — but there’s one small problem: your estimation is wrong. Always remember that you’re really just guessing. Think about how confident you are with your estimation. Would you bet your next month’s salary that you’ll come in within 20% of project costs?

For smaller operations, this probably isn’t too risky. If you underestimate a 20 hour project by 150%, you’ve only lost a little more than a week. If you underestimate a 5,000 hour project by 150%, you may be sentencing your company to an early grave.

The good news is the same as the bad: your estimation is wrong. Managers, project managers, account executives, and clients all know that estimations are wrong. If you find out that your estimation is way off balance, you can probably remedy it somehow. As long as you accept the fact that you’re wrong early on, finding out you’re wrong isn’t so painful later on down the road.

Now let’s hear what estimation tips you’ve learned!

WPF Recap

Windows Presentation Framework is Microsoft’s answer to developing Windows applications. It’s Microsoft scrapping everything it once knew about Windows application (front-end) development and creating a whole new set of tools, languages, and paradigms for creating interfaces.

Overview

The most heavily boasted feature of WPF has been its use of XAML (eXtensible Application Markup Language) for creating interfaces. XAML is a declarative XML language for instantiating interface objects. XAML is extremely reminiscent of HTML, although it is much, much, much more powerful. Here is a sample XAML file and the resulting application:

<Window x:Class="OfferBrowser.MainWindow"
    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
    Title="OfferBrowser" Height="300" Width="300"
    >
    <StackPanel HorizontalAlignment="Center" VerticalAlignment="Center">
        <TextBlock Text="Building applications in WPF is suprisingly simple now." HorizontalAlignment="Center" />
        <Button>Sure is!</Button>
    </StackPanel>
</Window>

The XAML above compiles into this Windows Application

XAML is immediately relevant for three reasons:

1. XAML at once makes advanced OO concepts accessible to web developers through an XML-flavored language that they can understand.
2. XAML makes for much faster application interface development.
3. XAML makes for drastically more readable code: you can look at a XAML document and have an understanding for the look-and-feel of the application.

More than interface: Vectors

In addition to laying out interface elements like <Button />s, XAML can be used to describe complex vector objects. Let’s say you wanted to lay out a nice vector star in XAML. You might have a piece of code that looks like this:

<Path
    Height="14.682"
    Width="15.437"
    Stretch="Fill"
    Data="M 61.3431396484375,0 C61.3431396484375,0 80.2991943359375,38.40919494628906 80.2991943359375,38.40919494628906 80.2991943359375,38.40919494628906 122.686279296875,44.56840515136719 122.686279296875,44.56840515136719 122.686279296875,44.56840515136719 92.01470947265625,74.46580505371094 92.01470947265625,74.46580505371094 92.01470947265625,74.46580505371094 99.25527954101562,116.68159484863281 99.25527954101562,116.68159484863281 99.25527954101562,116.68159484863281 61.3431396484375,96.75 61.3431396484375,96.75 61.3431396484375,96.75 23.430999755859375,116.68159484863281 23.430999755859375,116.68159484863281 23.430999755859375,116.68159484863281 30.67156982421875,74.46580505371094 30.67156982421875,74.46580505371094 30.67156982421875,74.46580505371094 0,44.56840515136719 0,44.56840515136719 0,44.56840515136719 42.3870849609375,38.40919494628906 42.3870849609375,38.40919494628906 42.3870849609375,38.40919494628906 61.3431396484375,0 61.3431396484375,0 z"
    Fill="#FFFFFFFF" Stroke="#FF000000" />

The numbers in the Data attribute are nonsense upon first glance: but you shouldn’t ever have to deal with that particular aspect. There are XAML exporters for nearly every professional vector graphics tool: Adobe Illustrator, Adobe Fireworks, Microsoft Expression Design, etc. The huge win here is that you can interact with design elements as you would interface elements. Instead of going through hoops to make a button display like a vector drawing, you can simply export the exact vector object and use it inside of a <Button>.

In fact, if we take the above <Path /> object and substitute it for the “Sure is!” text inside the <Button /> above, we get the following result:

A XAML vector object inside of a button

This interface element will scale without any work since it is a vector object. If you increase the size of the Path or the Button, your star will scale along with it. This is a pretty big concept since integrating your design elements with your interface elements effectively destroys the barrier to resolution-independent application development.

More than interface: 3D Objects

In addition to supporting 2D vector objects, XAML has the capability to represent 3D models in XAML. We’re talking full-blown 3D models extracted from your favorite 3D modeling application.

Fairytales of separation of functionality from interface

In Microsoft’s fairytale land, XAML is the answer to this thing that started with the whole codebehind concept so many years ago: the separation of functionality from interface. To web developers who are used to this strict separation with XHTML, CSS, and Javascript: the concept is at once understood. The idea is that the interface can be developed independently of the functionality of an application. Designers can write XAML to their heart’s content while programmers work on the back-end files.

This is nice in theory: but breaks down during implementation. During the project I was working on, the XAML file I was working on with one other engineer encountered ten subversion conflicts in a total of 11 checkins over the course of one day. That is proof enough to me that the format and syntax of the XAML files is inherently tied to the codebehind partial class, and any supporting libraries it may depend on.

Insult is added to injury from the fact that if an application will not build, you cannot see the interface. The previewing functionality in Visual Studio and Expression Blend is amateur at best, and when there is any error in any supporting library, you simply can’t launch the application. This means all interface development comes to a halt until the back-end programmers are given time to fix it. This makes complete sense from an application development standpoint, but zero sense to interface designers.

Conclusion

XAML is a huge step forward in application development. XML-based declarative languages like XAML and MXML are clearly the way that rich interface development is heading. Soon enough, anyone who chooses to tout themselves as a front-end developer will need to become with this method of programming (it is a new paradigm to understand). It’s fair to note that XAML is the same language used for Microsoft’s Silverlight platform as well. While there are still clearly some pain points between separation of functionality and structure, all in all: XAML is a good first-stab that solves many problems: resolution independent applications, integrating artwork, cleaning up code bases, and making application interface accessible to a broad range of developers.