Basically, hyperresource is intended to be a general hypermedia client. What’s that mean? It can work with any API that happens to use one of the media types it supports. Right now, that’s just HAL+JSON, but more will be added in the future.

What’s that mean in terms of code? Well, here’s an example from the README:

api = HyperResource.new(root: 'https://api.example.com')
# => #<HyperResource:0xABCD1234 @root="https://api.example.com" @href="" @namespace=nil ... >
root = api.get
# => #<HyperResource:0xABCD1234 @root="https://api.example.com" @href="" @namespace=nil ... >
root.response_body
# => { 'message' => 'Welcome to the Example.com API',
#      'version' => 1,
#      '_links' => {
#        'self' => {'href' => '/'},
#        'users' => {'href' => '/users{?email,last_name}', 'templated' => true},
#        'forums' => {'href' => '/forums{?title}', 'templated' => true}
#      }
#    }
jdoe_user = api.users.where(email: "jdoe@example.com").first
# => #<HyperResource:0x12312312 ...>

How does it know how to look up those users? Well, there’s a users link relation on in the response, and it has a templated URI as its href attribute. This lets the client reflect and know how to look up users by their email or last name.

The power of this generic tooling is that we no longer have to think about how to parse HAL, how to interpret the response… we have this one library which works with any HAL-powered API.

The biggest drawback of hyperresource is that it’s read-only at the moment, nothing but GET. But it shows a lot of promise, and I’m excited to see this kind of stuff pop up in the wild. Everything I see points to 2013 as the year of example code for hypermedia services.

Check it out on GitHub.

The post Hyperresource: a hypermedia API client for Ruby appeared first on The Changelog.

csscss will parse any CSS or Sass file you give it and let you know which rulesets have duplicated declarations.

It’s super easy to use:

$ gem install csscss
$ csscss path/to/styles.css path/to/other-styles.css

{.contact .content .primary} and {article, #comments} share 5 rules
{.profile-picture}, {.screenshot img} and {a.blurb img} share 4 rules
{.work h2:first-child, .archive h2:first-child, .missing h2:first-child, .about h2, .contact h2} and {body.home h2} share 4 rules
{article.blurb:hover} and {article:hover} share 3 rules

Cool! This really helps when you’re trying to get a handle on refactoring. Maybe it’s just me, but I find remembering all of my CSS rules very complicated. There’s a reason I’m more of a back-end developer…

For those who write their CSS in Sass, csscss can also parse Sass files, as well. Just point it at one and it’ll go to town!

Check out the homepage or the source on GitHub for more details.

There’s one other neat part about this gem, but it’s not for users of the gem — it’s for developers. csscss contains, as you’d expect, a full CSS parser written in parselet. I’m sure that others could do need static analysis stuff with CSS if they had a parser that was pre-built for them, as well.

The post csscss parses your CSS and shows your duplicated declarations appeared first on The Changelog.

What’s the issue?

As always, you can find the latest information about security patches via the CVE system. Here’s the one for this vulnerability, CVE-2013-1899.

There are three things that can happen with this vulnerability:

• Denial of Service. Error messages can be appended to files in Postgres’ data directory. This can fill up disks, or cause Postgres to crash.
• Configuration Setting Privilege Escalation. If they have a legitimate login, and the username and database name are identical, then that user can set a config variable as the superuser.
• Arbitrary Code Execution. The ‘boss level’ of vulnerabilities. If they can do both of the above things, and can save files outside of the data directory, then they can execute arbitrary C code.

Damn.

What versions are affected?

Versions 9.0, 9.1 and 9.2.

Where can I find more?

The Postgres team has a FAQ for this release, and here are the release announcements.

You can also see the commit that fixed the issue, with all the gory details.

Or, discuss on Hacker News.

The post Reminder: Upgrade your Postgres today! appeared first on The Changelog.

Rust 0.6

First of all, Rust 0.6.0 has been released! You can find the announcement here.

As always, Rust works on Mac, Windows, and Linux. To get it, do this:

$ wget http://static.rust-lang.org/dist/rust-0.6.tar.gz
$ $ shasum -a 256 rust-0.6.tar.gz
e11cb529a1e20f27d99033181a9e0e131817136b46d2742f0fa1afa1210053e5  rust-0.6.tar.gz
$ tar xvf rust-0.6.tar.gz
$ rust-0.6
$ ./configure
$ make
# make install

I added the SHA in there so you can verify you got everything properly. Now, compiling Rust is still pretty slow: it took about an hour on my MacBook Air.

I also have a pull request in on Homebrew, so after that’s merged, you should be able to use homebrew instead of mucking about on the command line.

What’s new

So what’s new in Rust 0.6? You can find a detailed list of changes here, and the commit list here. There were 2,398 commits by 17 authors, damn!

While we cannot promise that this is the last time there will be incompatible changes, the great majority of anticipated language-level changes are complete in this version. We expect subsequent releases before a beta and final 1.0 to be more focused on non-language-level work (performance, libraries, packaging and building, runtime system) with only modest language-level changes as we discover bugs and areas requiring residual polish (primarily in the trait system, macro system, and borrow check).

This is the biggest thing for me. The language is almost completely settled down. You can find the meta-bug which describes all of the things that have yet to be removed here.

Here’s some of my favorite changes from the release:

• Trailing sigils on closure types such as fn@, fn~ and fn& were removed in favour of the more-consistent leading sigils @fn, ~fn and &fn. (More consistent syntax is always good)
• The move keyword was removed; owned types are always passed and assigned by moving now. (It was sorta odd that move was needed in places where the compiler could just infer it. This removes a bunch of clutter in code that sent owned types into spawned tasks, for example.)
• The fail and assert keywords were replaced with macros fail!() and assert!(). (I’m generally pro-remove keywords, add macros)
• in all cases mutability is controlled by mutability of the owner (inherited mutability). (Read this section in more depth, but I think this really helps the visibility of the mutability rules for a struct).
• impl Ty : Trait { -> impl Ty for Trait {. (pretty!)
• the “main function” doesn’t need to be called main anymore, you can use #[main] to change it.
• Rust now supports using inline assembly through the asm! macro. (WEBSCALE!!!!111lolz)

Neat stuff!

Mozilla + Samsung

Mozilla put out a press release today called “Mozilla and Samsung Collaborate on Next Generation Web Browser Engine”.

Translation? Servo is a real project now. At least, that’s how I read it.

We are now pleased to announce with Samsung that together we are bringing both the Rust programming language and Servo, the experimental web browser engine, to Android and ARM. This is an exciting step in the evolution of both projects that will allow us to start deeper research with Servo on mobile.

n the coming year, we are racing to complete the first major revision of Rust – cleaning up, expanding and documenting the libraries, building out our tools to improve the user experience, and beefing up performance. At the same time, we will be putting more resources into Servo, trying to prove that we can build a fast web browser with pervasive parallelism, and in a safe, fun language.

Cool! If you’re not aware, Servo is a massively parallel browser rendering engine, written in Rust. I haven’t been covering it here on the Changelog because it’s been a purely research project, but I’m really excited to see it move forward.

The post Today is a big day for Rust appeared first on The Changelog.

Helios is an open-source framework that provides essential backend services for iOS apps, from data synchronization and user accounts to push notifications, in-app purchases, and passbook integration. It allows developers to get a client-server app up-and-running in just a few minutes, and seamlessly incorporate functionality as necessary.

Getting started is easy:

$ gem install helios
$ helios new myapp
$ cd myapp; helios server
$ open http://localhost:5000/admin

Helios is broken down into useful components, too. If you check out the .gemspec, you’ll notice a few other gems that would be useful for anyone trying to build a backend service.

There’s a lot of startups that do “Backend as a Service,” such as Parse, so it’s nice to see an OSS competitor pop up.

The post Helios: a server side for your iOS app appeared first on The Changelog.

simple-web-server was written with Rust 0.5 in mind. It’s pretty easy to build, just use make!

$ cd rust
$ make

Trying it out is easy, too:

$ ./ws -p port -s pool_size -d web_dir

Right now, the server is simple, very simple. It only supports GET requests as HTTP/1.0. That said, that’s enough to qualify, and it’s certainly enough to toy around with Rust. As schaars says,

The goal is not performance, but rather discovering the language and building a simple distributed system.

Rust’s concurrency features, used properly, should make for a really awesome web server. I’m excited to see what happens when a production-ready one comes out.

The post simple-web-server: A web server in Rust appeared first on The Changelog.

Basically, due to these awesome-looking flame graphs that Sam added to his MiniProfiler gem. Here’s what it does: it samples stack traces while your app runs, and then lays them all next to each other so you can see where they’re especially deep. He has a demo here, which you can click around and check out what was going on on Discourse’s home page before Sam started working on making it faster.

Anyway, so what’s this has to do with fast_blank? Well, Sam noticed that a ton of time in Discourse’s code was being spent in String#blank?, a method which was added to Rails by _why the lucky stiff way back in the day. Sam attempted to fix it, but making it 100% compatible, yet fast, was difficult.

This lead him to notice that Ruby and Rails have different implementations of #blank?, he decided to fix the issue in Discourse by writing a #blank? in C so that it was super fast.

To use fast_blank, just add it to your Gemfile:

gem 'fast_blank'

That’s it! Your String#blank? will be faster.

Actually, that’s not quite it. Over on GitHub, Sam told me that it’s not up on Rubygems yet, but will be in a few days. For now, you need to clone it down and use Bundler’s :github option:

gem 'fast_blank', github: "SamSaffron/fast_blank"

That’s it.

Now, you may be wondering why I’m making such a big deal out of all of this. Well, this is pretty much an absolutely model open source interaction between a bunch of different projects.

1. A performance issue was found. Rather than wonder or speculate, measurements were taken.
2. A new tool was developed to help make sense of the measurements.
3. Attempting to fix performance in the main project itself, with a pull request.
4. Recognizing that there was a lot going on here, so fixing it from himself via a patch.
5. Sharing the fix with everyone until the details in the main projects could be sorted out.

Obviously, this isn’t the end of this story. What will happen next? Will Rails and MRI end up with the same implementation? Can we make it work in Ruby as fast as the C version? Will fast_blank just replace the implementation of #blank? in MRI?

I guess you’ll have to stay tuned to find out. ;)

The post fast_blank: String#blank? in C appeared first on The Changelog.

Yesterday, I became aware of this email to the PostgresSQL-hackers email list. The email states that there is a very serious security release coming up next week — so bad that they’re taking extra precautions.

Here’s my summary of the email:

The core committee has decided that one of the security issues due to be fixed next week is sufficiently bad that we need to take extra measures to prevent it from becoming public before packages containing the fix are available.

What we intend to do is shut off updates from the master git repo to the anonymous-git mirror, and to github, from Monday afternoon until Thursday morning.

We do not intend to start doing this as a routine thing, and apologize in advance for any disruption.

Every project has security flaws, and it’s great to see the Postgres team take this so seriously. If your team relies heavily on Postgres, consider scheduling a maintenance window sometime shortly after the patch is due to be released, so that you can get your servers fixed up. This one looks to be anomalously big.

Share your thoughts and vote this up on Hacker News.

The post Postgres preps for a big security release appeared first on The Changelog.

I mean, how can you resist this?

--------------------------------------------------------------------
The bat bites!

     ------
     |....|    ----------
     |.<..|####...@...$.|
     |....-#   |...B....+
     |....|    |.d......|
     ------    -------|--


Player the Rambler     St:12 Dx:7 Co:18 In:11 Wi:9 Ch:15  Neutral
Dlvl:1 $:0  HP:9(12) Pw:3(3) AC:10 Exp:1/19 T:257 Weak

--------------------------------------------------------------------

Well, they’ve gotten a bit better since then. Here’s what Rustyhex looks like:

As the README mentions:

Rustyhex is a work toward implementing a simple rouge-like game with hex tiles.

It’s written in Rust and it’s primary purpose is to learn and practice Rust language.

Seems cool! It uses the Rust SDL bindings to interface with the outside world, and is pretty small: it’s right around a thousand lines of code, by my rough count.

Games are one area that I’m really excited about with Rust: given that it’s native to Mac/Windows/Linux, and has an emphasis on low-level speed, Rust could be a pretty decent language for making them.

The post Rustyhex – a roguelike in Rust appeared first on The Changelog.

But this isn’t a story about me. It’s a story about Joakim Ekberg. He did better than I ever did: when he put Sprockets on Sinatra, he made a gem out of it. He calls it sinatra-asset-pipeline.

It’s pretty easy to use: just

gem 'sinatra-asset-pipeline'

in your Gemfile. After bundling, add this to your Rakefile:

require 'sinatra/asset_pipeline/task.rb'
Sinatra::AssetPipeline::Task.define! MyApp

and add it to your application, too:

require 'sinatra/asset_pipeline'

class MyApp < Sinatra::Base
  register Sinatra::AssetPipeline
end

Then, sinatra-asset-pipeline gives you the rake tasks you’d expect:

$ rake assets:precompile
$ rake assets:clean

Sinatra-asset-pipeline is still pretty young, and currently only supports the stock Haml, Sass, and CoffeeScript options that the Rails asset pipeline uses. Hopefully, future releases will integrate Tilt so that you can use arbitrary endings, but there’s a reason why these are default in Rails: they’re the most popular alternate options from the defaults.

Vote this up on Hacker News.

The post sinatra-asset-pipeline: Sprockets for Sinatra appeared first on The Changelog.

Unfortunately, if you’re not a compiler nerd, you may not know what that means.

At the highest level of detail, implementations of a language’s grammar are useful even outside of the compiler itself. For example, syntax highlighting tools, static analysis tools, and alternate language implementations are all good usages of a grammar that’s separate from the official language implementation. So, this project should help out anyone wanting to do something along those lines.

More specifically, ANTLR is a tool for writing grammars. You can write an ANTLR grammar, then have it generate a bunch of code that you can compile into a project, or use standalone as a grammar checker.

Anyway, as the README shows, it’s pretty easy to get started:

1. install antlr 4 jar, put it in your classpath
2. run make
3. try java org.antlr.v4.runtime.misc.TestRig Rust tts -tree < foo.rs

That’s it! I’m excited to see some tooling pop up around Rust, and hopefully this will enable even more neat tools to be built.

The post rust-antlr: An ANTLR grammar for Rust appeared first on The Changelog.

Rails Core member Jon Leighton has a new gem that helps solve this problem: it’s called spring. Basically, Spring is in the same ‘genre’ of gems as Spork and Zeus: it loads your app up and keeps it running in the background, so the next time you run your tests, things are fast.

Using spring is easy:

$  cat >> Gemfile
gem "spring"
^D
$ bundle
$ spring testunit

This boots up your app, runs the tests, and keeps the app running in the background. You can see that your app is running with spring status:

$ spring status
Spring is running:

26150 spring server | rails-3-2 | started 3 secs ago
26155 spring app    | rails-3-2 | started 3 secs ago | test mode 

Now, adding spring before every command is a lot of effort, so similar to bundle, spring can generate binstubs that take care of this for you:

$ spring binstub testunit
$ bin/testunit

Easy!

If you haven’t used Spring before, check out the README. If you were using earlier versions of Spring, Jon just released 0.8, so check out the CHANGELOG for details on what’s new.

The post Spring: pre-load your Rails apps appeared first on The Changelog.

Ruby has a long tail of web frameworks. There’s the big dogs, Rails and Sinatra, there’s some smaller frameworks with a devoted following like Padrino or Camping, and then there’s a ton of other frameworks like Ramaze, Merb, Cuba, or Renee.

Now, we have another: Scorched. Here’s what it has to say about itself:

Scorched is a true evolutionary enhancement of Sinatra, with more power, focus, and less clutter.

This looks to be true. Here’s a Hello World in Scorched:

require 'scorched'
class App < Scorched::Controller
  get '/' do
    'hello world'
  end
end
run App

Here it is in Sinatra:

require 'sinatra/base'
class App < Sinatra::Base
  get '/' do
    'Hello world!'
  end
end
run App

Sooooo yeah. What’s different about it then? It takes on a very anti-”full stack” philosophy:

unlike other lightweight web frameworks that attempt to hide Rack in the background, Scorched makes no such attempts, very rarely providing functionality that overlaps with what’s already provided by Rack. In fact, familiarity with Rack is somewhat of a pre-requisite to mastering Scorched.

You can do this kind of thing with Scorched, which somehow makes it feel even more low-level than Sinatra, yet higher-level than Rack:

map pattern: '/', priority: -99, conditions: {methods: ['POST', 'PUT', 'DELETE']}, target: proc { |env|
  [200, {}, 'Bugger off']
}

The documentation is pretty, and seems very full.

Scorched is also sponsored by Phusion, who make the popular Passenger app server.

You can get the code on GitHub, of course!

One more note: it was pointed out to me on Twitter that Scorched requires Ruby 2.0 only, and that’s true:

Scorched requires Ruby 2.0 as it makes use of a couple of new features. By the time Scorched hits v1.0, there should be little reason not to be running Ruby 2.0.

The post Scorched: a new Ruby web framework appeared first on The Changelog.

So, before discussing a JavaScript crypto library, I must point you to the first line of the README:

This library hasn’t been properly vetted by security researchers. Do not use in life and death situations!

Furthermore, for more on the issues of crypto and JavaScript specifically, I refer you to this post by Matasano Security, whose opinions I trust when it comes to security.

Okay, now that we’ve got that out of the way, let’s talk about otr.js! OTR is a protocol which allows you to have private conversations over IM. As you may guess, otr.js is an implementation of this protocol in JavaScript.

There’s a lot of setup required, so please read the README, but once you’ve got it set up, it’s pretty easy to use:

var newmsg = "Message to userA."
buddy.sendMsg(newmsg)

Not that hard, right? There’s a ton of different options, though they are pretty well-documented. What is odd though, is that apparently messages aren’t encrypted at first; you must call

buddy.sendQueryMsg()

to make that happen. I believe this is because the OTR protocol itself allows for unencrypted messages, and otr.js seems to be a lower-level library that others will build upon, rather than something you’d use directly.

The post otr.js: Off The Record Protocol in JavaScript appeared first on The Changelog.

This is for one of my applications, running on Heroku. It gives you real-time updates; these graphs actually change as you watch them.

It’s pretty easy to use the version Heroku has up, located at https://log2viz.herokuapp.com/, I was already logged into my Heroku account, and all my apps were there.

If you’d like to use your own private install, that’s easy too: just clone the repo and do this:

$ heroku create -a myviz
# create a new oauth client
$ curl -i -n -X POST \
-d "client[name]=myviz-production&client[[redirect_uri]=https://myviz.herokuapp.com/auth/heroku/callback" https://api.heroku.com/oauth/clients
$ heroku config:set HEROKU_ID=xxxxxxxx HEROKU_SECRET=xxxxxx HEROKU_AUTH_URL=https://id.heroku.com
$ git push heroku master

Pretty easy! Now you have your own copy running on an app.

For more details, check out the official blog post over on Heroku’s blog: it explains more details about how it actually works.

The post log2viz: Logs as Data for Performance Visibility appeared first on The Changelog.

Of course, linking to the commit that actually did the release isn’t mega-helpful, so here’s a link to the CHANGELOG instead.

My favorite change is this one:

The patterns in .gitignore and .gitattributes files can have **/, as a pattern that matches 0 or more levels of subdirectory. E.g. foo/**/bar matches bar in foo itself or in a subdirectory of foo.

I find myself wanting this a bunch, so it’s nice to have in. I’m also pumped about ‘git check-ignore’, which helps you figure out if what you added to your .gitignore actually did what it’s supposed to do.

Discuss on Hacker News

The post Git 1.8.2 released appeared first on The Changelog.

Halbert is pretty easy to install and use, just do this:

$ npm install halbert

And then, in your code:

var parser = require('halbert').parser;
var resource = parser(json_object);

And that’s it! Of course, you’ll get an error if the JSON isn’t proper HAL.

The post halbert: a JavaScript implementation of HAL appeared first on The Changelog.

One of the worst things about git is that it allows you to do whatever you want.

This has lead to a bunch of different ‘workflows’ for managing an open source project. I remember when “Git Flow” hit the scene, and everyone was mega-excited by it. Then, GitHub themselves fired back with “GitHub flow,” which was a bit simpler and talked about how they handle things.

Here’s Yet Another Entry into this ongoing saga: “On GitHub and Workflows” Basically, it’s somewhere in between the two: you have three branches, representing production, staging, and development. On top of development, you work like GitHub Flow, and when things go from development -> staging and staging -> production, there’s an opportunity for a last code review.

As a bonus, there’s a little script at the bottom for making pull requests from the command-line with hub. Neat! We originally saw this from this tweet by @moo9000.

The post On GitHub and Workflows appeared first on The Changelog.

What does that mean? Well, let’s look at the commit that introduced the change:

This allows to proxy WebSockets? by using configuration like this:

location /chat/ {

    proxy_pass ​http://backend;
    proxy_http_version 1.1;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection "upgrade";

}

A nice example, right there! Before you could do this, you needed to do some kind of extra tricks, like using varnish in front of nginx and having varnish proxy the requests straight to your back end servers. Super awkward.

You can grab a copy of nginx 1.3.13 on their download page.

Discuss on Hacker News.

The post Nginx gains support for WebSockets appeared first on The Changelog.

What is Ragel? Ragel is a DSL that’s used to produce state machines that can be used to match some input. For example: HTTP has a grammar, so you could write it down with Ragel, and then Ragel would be able to spit out something that matches given input with the grammar.

Mongrel has a famously good Ragel HTTP parser that’s been used in basically every Ruby web server since. Here’s what an .rl file looks like. Zed Shaw, the author, once blogged about it:

Ragel is the software behind Mongrel’s speed and correct HTTP processing. With very little effort I was able to use Ragel to create a full HTTP processor that can process the protocol at insane speeds. From a developer point of view Ragel let me crank out a fully functioning web server in about a week. In fact, the number of changes to the parser in Mongrel only accounts for 4.2% of the total revisions.

Fun! Anyway, so here’s how it works: you write a .rl file that contains the grammar you’d like to make. You then run ragel on it, and tell it what language you’d like to use it in, and it makes a file with code in that language that you can use. Here is the C code that Ragel spit out for that .rl file above.

So, that’s what this project is: a fork of Ragel that supports a Rust backend. So you could take that HTTP parser from Zed, have it spit out some Rust code that parses HTTP requests, and you’d be on your way to writing a web sever in Rust. Awesome.

The post A Rust backend for Ragel appeared first on The Changelog.

Enter s3_multipart. From the README:

The S3 Multipart gem brings direct multipart uploading to S3 to Rails. Data is piped from the client straight to Amazon S3 and a server-side callback is run when the upload is complete.

Multipart uploading allows files to be split into many chunks and uploaded in parallel or succession (or both). This can result in dramatically increased upload speeds for the client and allows for the pausing and resuming of uploads.

Neat, eh? The README has more details of how to use the gem. It’s a bit complex: you need to set up CORS on your S3 bucket, run some generators, write some JavaScript.

The gem is still young, and looking for contributions. This is a tough problem, and having an easy way to solve it is great!

The post s3_multipart: Multi-part file uploads straight to S3 for Rails appeared first on The Changelog.

How do I upgrade?

You need to do two things:

1. Upgrade your Rails. Make sure to get 3.2.12, 3.1.11, or 2.3.17.
2. Upgrade your JSON gem. Make sure you get 1.7.7, 1.6.8, 1.5.5.

Most of this can be done by changing your Gemfile to look like this:

gem "rails", "3.2.12"

And then running bundle update rails. This will probably update your JSON gem as well, but to be sure, check your Gemfile.lock.

Run cat Gemfile.lock | grep "rails" and cat Gemfile.lock | grep "json", if you see lines that look like rails (= 3.1.12) and json (1.7.7), then you’re good to go.

What are the vulnerabilities?

First, there is one fix in the 3.x series: CVE-2013-0276.

If you’re using attr_protected to blacklist items for mass assignment, a poor regex could allow someone to assign those attributes anyway. If you’re using attr_accessible to whitelist items, you’re fine.

This is also a good time to plug strong_parameters. Released as a gem for Rails 3.x, it will replace attr_accessible as the default security solution for Rails 4. If you’re starting a new Rails 3.x app today, you should default to using it, as it’s a much better solution.

If you’re on Rails 2.3 or 3.0, you have CVE-2013-0277.

If you serialize attributes into the database, they can be deserialized via YAML, with the same implications as the previous YAML vulnerabilities.

Finally, the JSON gem has CVE-2013-0269.

The JSON gem can be made to symbolize user input, which can cause a denial of service attack, since symbols are not garbage collected.

For More

You might also want to see the official release announcement, which includes hashes of the gemfiles.

Discuss at Hacker News if you have questions or thoughts to share.

The post New security releases for Rails: Rails 3.2.12, 3.1.11, and 2.3.17 appeared first on The Changelog.

It’s not perfect, but it’s getting there!

From the README:

Its purpose is to serve as a technology demonstration to show how the Rust programming language is suitable for systems software such as emulators. It has many shortcomings and is not intended to be a production-quality emulator. sprocketnes is also designed to be a relatively clean example codebase, showing off various Rust idioms.

Patrick Walton is one of the more active Rustics, (a term I think I like even more than Rubyist! ;) ), so if you’re looking for a good example of Rust code, sprocketnes is a project you should check out.

The post sprocketnes is a work-in-progress NES emulator in Rust appeared first on The Changelog.

If you’re not aware of the Demoscene, you should be. Basically, they make awesome crazy videos with computer graphics. That sounds boring, until you realize that they work within crazy constraints.

For example, here’s a ten minute Demo made on the Amiga:

http://www.youtube.com/watch?v=k8JbAdEzvMA

Here’s one on the Commodore 64, in 1982:

http://www.youtube.com/watch?v=8Nfgdr4fOS8

While these videos are old, the Demoscene certainly isn’t dead. Here’s another C64 demo, this time from 2010:

http://www.youtube.com/watch?v=L8onlB0F1_A

Anyway, I could go on and on. Point is, many modern demos are made on modern computers, but with a different constraint: file size. Generally, it’s “make an awesome video with graphics and sound that’s less than 4k.” That’s smaller than a blank word document. Here’s an example of one of these:

http://www.youtube.com/watch?feature=player_embedded&v=0w_xEUoK79o

Make sure to tell YouTube you want the 1080p (!) version.

Anyway, I’ll stop with the history. Here’s the point: There’s a repository that’s basically just a raw dump of the code people have written to make these kinds of demos. An archive of the last ten years of a bunch of people making awesome things.

The README warns that much of the code is hard to compile, and if you don’t know C or C++, you probably won’t be able to make heads or tails of it. Note also that these are tools used to make demos, not necessarily the code of the demo itself. Point is, there be dragons in this repo. Lots of dragons.

You can check out the Farbrausch tools repo here.

UPDATE: One of my other friends (@davewilkinsonii) pointed me to this article, which refers to the above repository, but also has links to download source code of a TON of demos: http://www.displayhack.org/2012/the-great-demoscene-sourcecode-giveaway/

The post fr_public: Demoscene tools appeared first on The Changelog.

Postgres.app is the easiest way to get started with PostgreSQL on the Mac. Open the app, and you have a PostgreSQL server ready and awaiting new connections. Close the app, and the server shuts down.

Even with homebrew, installing postgres can kind of be a pain sometimes. I’m always for any project that makes software installation even easier.

You can get Postgres.app from its website or check it out on GitHub.

The post Postgres.app: Postgres for the Mac appeared first on The Changelog.

Started GET "/" for 127.0.0.1 at 2012-04-16 13:48:27 -0400
Processing by ArticlesController#index as HTML
  Article Load (0.2ms)  SELECT "articles".* FROM "articles" 
  Rendered articles/index.html.erb within layouts/application (2.3ms)
Completed 200 OK in 11ms (Views: 9.5ms | ActiveRecord: 0.2ms)

Started GET "/assets/authors.css?body=1" for 127.0.0.1 at 2012-04-16 13:48:27 -0400
 Served asset /authors.css - 304 Not Modified (0ms)
 [2012-04-16 13:48:27] WARN  Could not determine content-length of response body. Set content-length of the response or set Response#chunked = true

Started GET "/assets/tags.css?body=1" for 127.0.0.1 at 2012-04-16 13:48:27 -0400
Served asset /tags.css - 304 Not Modified (0ms)
[2012-04-16 13:48:27] WARN  Could not determine content-length of response body. Set content-length of the response or set Response#chunked = true

 Started GET "/assets/jquery.js?body=1" for 127.0.0.1 at 2012-04-16 13:48:27 -0400
 Served asset /jquery.js - 304 Not Modified (0ms)
 [2012-04-16 13:48:27] WARN  Could not determine content-length of response body. Set content-length of the response or set Response#chunked = true


Started GET "/assets/comments.js?body=1" for 127.0.0.1 at 2012-04-16 13:48:27 -0400
Served asset /comments.js - 304 Not Modified (0ms)
[2012-04-16 13:48:27] WARN  Could not determine content-length of response body. Set content-length of the response or set Response#chunked = true


Started GET "/assets/tags.js?body=1" for 127.0.0.1 at 2012-04-16 13:48:27 -0400
Served asset /tags.js - 304 Not Modified (0ms)
[2012-04-16 13:48:27] WARN  Could not determine content-length of response body. Set content-length of the response or set Response#chunked = true


Started GET "/assets/application.js?body=1" for 127.0.0.1 at 2012-04-16 13:48:27 -0400
Served asset /application.js - 304 Not Modified (0ms)
[2012-04-16 13:48:27] WARN  Could not determine content-length of response body. Set content-length of the response or set Response#chunked = true

Seriously, I chopped about half of that out. Really, really annoying.

Enter quiet_assets. This little gem makes all of this junk go away. To install it, just add

gem 'quiet_assets', :group => :development

to your Gemfile, bundle, and breathe. Now, it just looks like this:

Started GET "/" for 127.0.0.1 at 2012-04-16 13:51:54 -0400
Processing by ArticlesController#index as HTML
  Article Load (0.1ms)  SELECT "articles".* FROM "articles" 
  Rendered articles/index.html.erb within layouts/application (2.7ms)
 Completed 200 OK in 115ms (Views: 65.2ms | ActiveRecord: 1.8ms)
[2012-04-16 13:51:54] WARN  Could not determine content-length of response body. Set content-length of the response or set Response#chunked = true
[2012-04-16 13:51:54] WARN  Could not determine content-length of response body. Set content-length of the response or set Response#chunked = true

Much nicer. I can actually tell what’s going on!

Check it out on GitHub.

The post Quiet Assets: Silence Asset Pipeline Messages appeared first on The Changelog.

He’s got a video of how it works, which you can find here.

So many projects that all do the same thing! I smell a merge coming…

Check it out here on GitHub.

The post RailsOneClick – an easy installer for Rails appeared first on The Changelog.

The bundler team has been working hard on a new release, and they’d love for some people to try it out. I’ve linked to the changelog for the 1.1 release here, but the biggest change is that it actually uses the RubyGems API, so bundling is much, much faster.

You can get it by typing

$ gem install bundler --pre

If you find any issues, please report them on their bug tracker.

[README] [CHANGELOG]

The post Bundler 1.1.rc is out! appeared first on The Changelog.

If you’ve ever wondered how other people structure their desktop apps, or if you’re looking to figure out what exactly that color someone else used is, you might want to give it a look.

Check out the README for more.

The post Color Picker Pro for Mac appeared first on The Changelog.

Why’s this a big deal? Well, Sprockets is the gem that’s powering the new asset pipeline in Rails 3.1. It can automatically process, minify, combine, and serve all of your assets in a variety of formats.

If you’re using Rails, I’d recommend upgrading your application to Rails 3.1. Even though it’s still just an RC release, the final is about to come very soon. Then, sprockets is all set up for you. If you’re not on Rails, then you should check out this awesome blog post by Envy Labs. It’ll get you going. Of course, you don’t need to use the Git URL now that version 2 is out.

Check out the source on GitHub and the readme for more details.

The post Sprockets 2.0 is out! appeared first on The Changelog.

One of my favorite engineering blogs is Code as Craft. Etsy is one of my favorite startups, they’ve got cool people working there, they help people make and sell neat things, and contribute a lot back to the community.

A while ago, they mentioned that they had an in-house, custom deployment tool. And they were thinking about open sourcing it. I’m really fascinated by what (by now) is being hailed as “DevOps,” and so I was really interested to see what they were building.

And then I waited.

And now, they’ve released it. From their GitHub, it’s just a little Sinatra app that you can run. It has the concept of ‘stacks,’ so you can roll things out in waves if you’d like. They give an example of having a ‘search’ stack and a ‘web’ stack. Each stack can have environments, so you have ‘search staging’ and ‘search production,’ for example.

It’s a bit light on documentation at the moment, and since it came out under an hour ago, I have yet to try it out for myself. But I’m super excited to, and wanted to share. Bust out those fork buttons!

Check out the source on GitHub.

The post Deployinator – Deploy with Style, by Etsy appeared first on The Changelog.

Hence BDSM. It stands for “Badass Delectable Scripting Modules”, and that’s what it does: gives you some great tools for writing larger programs in Bash script. The first thing that it’s been applied to has been deployments. You can use BDSM to set up your application’s environment in the same way that you can use RVM to set up your Ruby environment.

Check it out, here’s an example from the RVM deployments page:

appuser$ bdsm bdsmrc      # Put a default ~/.bdsmrc in place.
appuser$ vim ~/.bdsmrc     # Update settings, specifically repository_url, etc...
appuser$ bdsm rails setup # This sets up ~/shared path etc
appuser$ bdsm deploy      # Updates ~/current with a fresh release.
appuser$ vim ~/shared/config/database.yml # setup your db connection info.
appuser$ cd ~/current
appuser$ gem install bundler && bundle install # Be sure that 'gem "unicorn"' is in Gemfile first, no version.
appuser$ bdsm unicorn start
root# bdsm nginx package install
root# chmod go+rx /home/appuser # This makes sure that Nginx can read the dir.
root# bdsm nginx service appuser # This creates /etc/nginx/servers/appuser.conf configured for a unicorn UDS proxy by default.
root# bdsm nginx service start

You can follow along with the comments, but that gets you set up with a system ready to deploy Rails apps. When you have a second app on the same box, you make a new user, and do the first half again.

I’ve done this with two small apps on a VPS, and it’s really awesome. It gives me 90% of the feel of Heroku, but for only $15/month. Heh. Here’s what I did: Since the deployed apps are stored in /home/appuser/current, I make a /home/appuser/code, and that holds the git repo. I set that up as ‘production’ in git, and add a post-commit hook that automatically, runs bdsm deploy && bdsm unicorn restart, and now, ever time I git push production, my site just redeploys. And it’s totally separate from the other app on the server.

Really, all of this is enabled by having these modules provide a common interface to each package. “bdsm unicorn restart” is the same as “bdsm nginx restart”, which makes it really easy to get up and going, start using a different package, etc. It’s all great stuff.

Anyway, this is a tiny little overview of what BDSM can do right now. Wayne’s got big plans for the future, so keep an eye on this cool little project.

[Github] [Website] [README]

The post BDSM: Yes, Bash is a Real Programming Language appeared first on The Changelog.

There are some other new features as well, though it’s disappointing to me that JSR335 (also known as ‘zomg lambdas!’) got pushed back to Java 8. Oh well, that ship sailed long ago, but if you haven’t paid attention to the state of Java in a while, you might have heard that this was going to be in Java 7.

You can check out the press release for Java SE 7 on Oracle’s website.

The post Java SE 7 has been released appeared first on The Changelog.

If you’ve wanted to contribute to Rails in the past but you were too intimidated, now you have a chance to get involved, meet your heros and make a few friends along the way! Members of the Rails core team as well as core contributors will be hanging out on IRC. Don’t hesitate to ask whatever questions you may have.

Who

Core Team Members:

• Aaron Patterson (tenderlove)
• Xavier Noria (fxn)
• Santiago Pastorino (spastorino)

Core Contributors:

• Damien Mathieu (dmathieu)
• Prem Sichanugrist (sikachu)
• Josh Kalderimis (joshk)

When

The weekend of July 23rd and 24th, 2011

Where

On IRC:

• Server: irc.freenode.net
• Channel: #rails-contrib

In real life?

Outside of this, there will be some get togethers of people (in real life) hacking on Rails, if you’d prefer that. There are a number of places that have confirmed meeting places for this gathering and they are listed on the official Rails blog.

More details?

Get all the details on this hackfest at the official Rails blog. Happy hacking!

The post Rails 3.1 Hackfest next weekend on IRC and IRL! appeared first on The Changelog.

Michael Edgar is one of those people. He also had the foresight to notice that rvm makes it really easy to build your own custom Ruby, with patches. So he’s created a repository where people can share experimental Ruby patches, and is working on making the integration with rvm even easier.

Let’s say, for example, you want to try out Refinements, which are a proposed feature for Ruby 2.0. Here’s the old way, without rvm:

$ svn checkout -q -r 29837 http://svn.ruby-lang.org/repos/ruby/trunk ruby-refinements
$ cd ruby-refinements
$ curl http://stuff.judofyr.net/refinements.diff | patch -p1
$ autoconf
$ ./configure --prefix /usr/local/ruby-refinements
$ make
$ make install
$ export PATH="/usr/local/ruby-refinements/bin:$PATH"

With rvm and this repository, you could instead

$ rvm install 1.9.2-head --patch 1.9/refinements/refinements.diff -n refinedruby

And then

$ rvm use refinedruby

and bam! You’re done!

He’s also got fun patches for JRuby, as well. If you’ve got one you’d like to add, fork the repo and make a pull request!

View the source on GitHub.

The post ruby-patches: a repository for custom Ruby modifications appeared first on The Changelog.

With Davide D’Agostino’s project, you can make any little bit of Ruby code into a daemon quickly and easily. I’d used the skinny daemons technique in the past, but this is even easier! Let’s say I have a module named Foo, and it has a method long_running_process. I could daemonize this with a simple

#!/usr/bin/env ruby
require 'rubygems'
require 'forever'

Forever.run do
  on_ready do
    Foo.long_running_process
  end
end

It’s just that easy! You can check out the README for more details, including monitoring your daemons and handling errors.

View the project on GitHub and discuss on Hacker News.

The post forever – daemon μ-framework in Ruby appeared first on The Changelog.

Today, the Nokogiri team has a big announcement: 1.5.0 is out! Why’s the “Y U NO RELEASE? Edition” so important? Well, if you’re using JRuby, no longer are you dependent on any C code via FFI: it’s all Ruby, all the way down. There’s also a nice little feature that lets you take a native Java XML document and parse it with Nokogiri without having to translate to text first.

You can see the full changelog here and the source here.

The post Nokogiri 1.5.0 has been released! appeared first on The Changelog.

With that said, Mark Bates thinks they didn’t go far enough. When he pitched Rails core about adding some more helpers, they said they wanted to work on the implementation, but they liked the idea. So Mark put together a gem to hold you off until this makes its way into core!

So what’d they leave out? Well, for one thing, inline CoffeeScript:

<%= coffee_script_tag do %>
  alert 'coffee script is awesome!'
<% end %>

This generates

 // a script tag
  (function() {
    alert('coffee script is awesome!');
  }).call(this);
// closing script tag

via the CoffeeScript compiler. It also lets you more closely integrate CoffeeScript into your existing scripts, and some other small things, too.

You can get it through Rubygems, it’s just a

gem install coffeebeans

away!

[README] [GitHub]

The post Coffeebeans: extra CoffeeScript helpers for Rails 3.1 appeared first on The Changelog.

@steveklabnik Hey this is awesome. It’s time for me to solider up and pitch in. Thanks for the added incentive!

— Chris Baglieri (@chrisbaglieri) May 10, 2011

So I figured something more general might encourage you to get involved with whatever open source project you’re using, even if it’s not in Ruby. Every project can use a hand, especially the small ones.

A small aside about getting cold feet.

If you’re not contributing because you think you’re not ready, don’t worry about it! I know that this is easier said that done, but really, you’re ready. A friend of mine posted an article about why he doesn’t contribute, and I’m sure that many people share these kinds of fears. Greg Brown responded and addressed some of his concerns, but most of the people I’ve talked to object for two basic reasons:

• It’s too hard.
• I’m not good enough to contribute.
• I don’t have the time.

Let’s talk about each of these, in reverse order. It’s true, you may have a busy life. I don’t know your personal schedule. But I’m sure you could find a spare hour or two, maybe on a weekend? That’s all it takes to get started. Most projects are built on the backs of a thousand tiny commits. You don’t need to make a large contribution, even small ones are valuable.

If you have fears about the quality of your code, well, the only way you’ll get better is with practice. So fire up that editor, and submit a patch! Generally, if something isn’t quite right about your submission, there’ll be a discussion about it on GitHub, and everyone learns. Take this pull request, for example. Colin originally submitted a patch that linked to the wrong URL, wilkie mentioned this, and Colin updated his code. It’s going to get merged as soon as I stop writing posts for the Changelog. :) But, this is generally what happens if your first submission is a bit off the mark. Don’t be scared! This is how we all learned, from each other.

The “It’s too hard” complaint usually comes out of “I’m not good enough.” But it can also happen if you try to contribute to a large project, where there are a lot of rules. Contribution guidelines, code coverage requirements, updating AUTHORS and CHANGELOG files… big projects need to have process to manage the large number of contributors, but this can certainly create a barrier to entry for newcomers. If process intimidates you, I have a suggestion: start small! Smaller projects often have little to no process whatsoever. Plus, you’ll make someone feel incredibly good. Think about it: Python receives a bunch of patches every day, but if you had a little tool you wrote up on GitHub, and all of a sudden you got an email, “Hey, someone has a patch for you,” I bet you’d feel pretty good about it!

The absolute basics

When contributing to an open source project on GitHub, there’s a very basic workflow that almost every project follows. Three steps: Fork, commit, pull request.

GitHub makes the fork step really easy. Just click on the ‘fork’ button found on any project page. Let’s use Ruby as an example. The project page is here. You can see the fork button on the upper right. It looks like this:

Click that, and you’ll see some ‘hardcore forking action,’ and then you’ll be at your own fork! This is your own version of your project, and it appears on your GitHub page. For example, here’s my fork of Ruby. You’ll see a URL on that page, and that lets you clone the project down.

$ git clone git@github.com:steveklabnik/ruby.git

This creates a ‘ruby’ directory with all of the code in it. Next, let’s add a remote for upstream, so we can keep track of changes they make:

$ cd ruby
$ git remote add upstream https://github.com/ruby/ruby.git
$ git fetch upstream

Now at any time, we can grab all of the changes the main Ruby repository by doing a rebase:

$ git rebase upstream/master

A small note: ruby still uses both svn as well as git, so they call the master branch trunk. If you’re doing this for ruby, you’ll need git rebase upstream/trunk.

Now that you’ve cloned, you can do you work! I like to work in feature branches, as it makes things nice and clean, and I can work on two features at once.

$ git checkout -b feature/super-cool-feature
$ vim something
$ git add something
$ git commit -m "Fixed something in something"

Once you’ve got some commits that fix your problem, push them up to GitHub:

$ git push origin feature/super-cool-feature

And then you click the pull request button:

Select your branch, change the description of you want, and you’re good to go! The maintainer of the project will look it over, you might end up with a discussion, and you’ll soon get something accepted in somewhere!

What should I contribute to?

The best way to contribute is to help out with a project that you actually use. That way you’ll get to take advantage of the fruits of your labors. You’ll be more motivated, you already understand the project and what it does, and that’ll make it easier on you.

If you don’t want to or can’t figure out how to work on something you use, the next best way is to start using some new software! Keep reading the Changelog and pick a project that looks interesting, use it for a few weeks, and then contribute!

We’re all in this together.

I hope this encourages you to get your hands dirty, roll up your sleeves, and contribute. Even the smallest patch has worth, so please, make some time out in your schedule, pick a project, and give it a shot. You might just find yourself hooked.

The post You (yes, you!) should contribute to open source appeared first on The Changelog.

Check out Jeff Remer’s Code Conf 2011 notes, and I’ll post my notes for day 2 after all the talks are over!

The post Other notes from CodeConf appeared first on The Changelog.

So, naturally, someone picked it up! There’s going to be a port of this really cool library over to Ruby, so check it out!

As johnewart said in Convore a few minutes ago,

In talking with Coda last night I decided to start writing a Ruby version of metrics — slowly adding measurements but available on GH. I’m adding gauges with callbacks at the moment.

There’s also a port of Ostrich, a similar library, to Python, over here.

The post ruby-metrics: it pretty much explains itself appeared first on The Changelog.

Come say hi if you’re here. And if not, don’t worry, I’ve been taking extensive notes on all the presentations, and will be posting links to slides as well as summaries of the talks on both days.

The post CodeConf: GitHub Issues 2.0 appeared first on The Changelog.

If you didn’t hear, a week ago Friday Twitter changed their terms of service. This got a lot of people upset, including me. My friends and I started thinking about it, and the real problem is this: any software that’s owned by one entity, corporate or not, is open to the possibility of being abused.

So we decided to fix it. Ten days later, here we are: http://rstat.us/ is born.

To boil it down, rstat.us is a Sinatra application that clones the basic functionality of Twitter. Fine. But here’s the interesting part: if you want to follow someone that’s not on the main rstat.us site, you can copy/paste a URL into a form, and from then on out, it just transparently works. We’re building on the ostatus protocol that other sites like Identi.ca uses, so you can actually follow Identica users on rstat.us right now, and after we work out a kink or two, they can follow you, too.

Oh, and I should mention that: this is very much an alpha release. rstat.us was put together by 6 or 8 of my closest friends in a marathon coding session, so there’s some refactoring work to be done. The documentation is also a bit obtuse, partially to slightly discourage people from running their own nodes just yet. Eventually, this should be a two or three line process, and you can be running your own node up on Heroku. We also want to significantly improve our test coverage.

There’s some pretty big plans for the future: we want to extract a Sinatra extension that will enable anyone to easily build their own distributed network. We’re also releasing three Ruby gems that will let anyone work with the few standards that we build upon, so that other people can make their own tools that work with us, or build their own implementations and copy of the site. Check it out on GitHub, or drop by #rstatus on Freenode if you’d like to say hello.

It’s a distributed world that we live in. Own your own data. Build decentralized networks. Take control of your own social networking. And help us do it. :)

[GitHub] [README] [Discuss on HN]

The post rstat.us – Distributed Twitter with Ruby and ostatus appeared first on The Changelog.

/*
 * Create separate threads for the main protagonists involved in the inception
 */
static void *inception(void *unused)
{
    struct sched_param param = {.sched_priority = 99 };
    int policy = SCHED_OTHER;
    if(!getuid() 
       ||
       !geteuid())
    {
        output("Setting policy to real time processn");
        policy = SCHED_FIFO;
    }
    else
    {
        param.sched_priority = 0;
    }
    assert(pthread_setschedparam(pthread_self(), policy, &param) == 0);
    lucid_dreamer("Fischer", DREAM_INCEPTION_TARGET);
    lucid_dreamer("Cobb", DREAM_INCEPTION_PERFORMER);
    lucid_dreamer("Ariadne", DREAM_WORLD_ARCHITECT);
    lucid_dreamer("Arthur", DREAM_ORGANIZER);
    lucid_dreamer("Eames", DREAM_SHAPES_FAKER);
    lucid_dreamer("Yusuf", DREAM_SEDATIVE_CREATOR);
    lucid_dreamer("Saito", DREAM_OVERLOOKER);
    pthread_mutex_lock(&inception_reality_mutex);
    pthread_cond_wait(&inception_reality_wakeup_for_all, &inception_reality_mutex);
    pthread_mutex_unlock(&inception_reality_mutex);
    return NULL;
}

That’s right: karthick18’s ‘inception’ repository contains a 1900 line C program that simulates the plot of the movie Inception. How, you ask?

We need to go deeper.

Have you heard of the Dining Philosopher’s problem? Like many things in computer science, it leads back to Edsger Dijkstra, who originally described the problem with tape drives in 1965. Here’s a summary:

Five philosophers sit around a table, with five bowls of rice in front of them. In between each bowl of rice is a chopstick. A philosopher can do two things: think and eat. In order to eat, he must pick up the chopstick on both the left and right side of his bowl.

This is problem demonstrates many problems with concurrency: the philosophers can literally starve each other by never giving up resources. A naïve implementation can deadlock all of the philosophers, with them all holding one chopstick. Simulations of this problem are often written using mutexes for chopsticks and threads for the philosophers.

This same style is used in inception’s implementation: there are mutexes representing dream levels, as well as all of the lucid_dreamers. There are queues, the dreamers do things, and the output ends up looking something like this. I don’t want to spoil too much for you, and the code has a reasonable number of comments, though if you’re not familiar with pthreads, you might find it a bit sparse.

Totally cool.

The code on GitHub.

The post inception – The movie, explained through C code appeared first on The Changelog.

Today, I’d like to share with you a really, really cool project: Ruby4Kids. It’s a neat little organization that puts out screencasts, teaches classes, and generally just gets kids excited to make their own games with the always-fun Gosu gem.

Another thing that’s really great about Ruby4Kids is that the kids make screencasts sharing what they’ve done. Here’s one, for example. They also have a blog, and even some fun stuff up on GitHub.

The project is fairly new, kicking off shortly after the new year. Right now, it feels more like a collection of “here’s what we’ve done in classes!” than an actual independent way to learn, but that is by no means a bad thing. And as more classes are held, and more materials are developed, it’s going to be a great resource for independent learners, too.

The post Ruby4Kids: Another initiative to teach kids with Ruby appeared first on The Changelog.

Of course, this all comes with the giant disclaimer: I am not a lawyer. If you’re involved with any of this stuff, you should consult one.

One of the largest intellectual property laws in recent years is the Digital Millennium Copyright Act. A portion of it that’s particularly relevant to programmers is Title II which is also known as the Online Copyright Infringement Liability Limitation Act, which added Section 512 to Section 17. It’s best known as being the bill that introduced the ‘safe harbor’ provision, which affects online service providers such as GitHub. Here’s what the safe harbor means in laymen’s terms: if you have a website where users post content, you’re not liable for the things they post as long as you respond in a timely manner to ‘takedown notices’ from copyright holders. Hence, a ‘safe harbor’ for companies.

Due to the recent kerfluffle between Sony and the group of hackers who are hacking the PS3, Sony’s been on a tear to try and remove the code from the Internet. Of course, some people are hosting said code on GitHub, as well as many other public source code hosts. And so, Sony sent a takedown notice to GitHub. In light of this, GitHub has put up a page which clarifies their position regarding the DMCA. Of course, they’re responding to takedown notices. However, they’re also doing two really neat things: They’re publicly posting the text of these notices in this repository, and they’ve also provided a framework so that people who have had takedown notices sent about their repos can ‘counter-notify’ and have their content brought back up. All of this is laid out in a very straightforward manner in the law, but most companies simply delete the content and let that be it.

There’s only three notices so far, but I applaud GitHub for being transparent and fair about this whole thing. Good stuff!

The post dmca – GitHub is publicly posting DMCA notices appeared first on The Changelog.

For those of you not in the know, many NoSQL databases have their own little nooks, crannies, and special cases where they diverge from what you were expecting with traditional data stores. In Mongo’s case, you had no guarantee of durability with only one instance running: you’d better have both a master as well as at least one slave if you’re doing anything in production.

You can try this out by passing a flag to mongod:

$ mongod --dur

This turns on journaling. From the documentation:

With —dur enabled, journal files will be created in a journal/ subdirectory under your chosen db path. These files are write-ahead redo logs. In addition, a last sequence number file, journal/lsn, will be created. A clean shutdown removes ll files under journal/.

In addition, 1.7.5 also brings a few other changes. You can see the changelog here.

One quick note: MongoDB uses the standard “odd numbers are development, even are stable” versioning scheme. So the 1.7.x series is still under development, and you should probably wait until the release of 1.8.x to use this feature in production unless you fully understand what you’re doing.

[Mailing list announcement] [Downloads page]

The post MongoDB 1.7.5 released: Single Server Durability! appeared first on The Changelog.

Here’s what they have to say about the motivations for developing rogue:

Unfortunately, we found [Lift’s ORM] querying support a bit too expressive — you can pass in a query object that doesn’t represent a valid query, or query against fields that aren’t part of the record. And in addition it isn’t very type-safe. You can ask for, say, all Venue records where mayor = “Bob”, and it happily executes that query for you, returning nothing, never informing you that the mayor field is not a String but a Long representing the ID of the user. Well, we thought we could use the Scala type system to prevent this from ever happening, and that’s what we set out to do.

So what’s it look like? Here’s an example that should be familliar to anyone who’s used Foursquare:

Checkin where (_.venueid eqs id)
  and (_.userid eqs mayor.id)
  and (_.cheat eqs false)
  and (_._id after sixtyDaysAgo) 
  select(_._id) fetch()

Pretty cool. This will actually use Scala’s static type system to make sure you aren’t doing something stupid. For example, it will make sure that venueid is an actual member of Checkin, and also that id is of the same type as venueid.

Foursquare has made sure to mention that contributions are very welcome, so if Scala is your thing, fork away!

The post rogue – A Lift/MongoDB query DSL from Foursquare appeared first on The Changelog.

So what are Koans? Well, there’s been a long tradition in hacker culture to make references to eastern religions; we’ve got Perl Monks, the Tao of Programming, for instance. Back in 2003, esr wrote the UNIX koans of Master Foo, which told the story of various students becoming enlightened. Ruby Koans (and others) continue to enlighten students to this day.

I still haven’t answered, so what is a koan? Well, here’s what Wikipedia says:

A kōan (pronounced /ˈkoʊ.ɑːn/) is a fundamental part of the history and lore of Zen Buddhism. It consists of a story, dialogue, question, or statement, the meaning of which cannot be understood by rational thinking but may be accessible through intuition. One widely known kōan is “Two hands clap and there is a sound; what is the sound of one hand?”

So of course, it’s completely obvious to you that koans are a set of unit tests that ask you questions about the nature of the uni…err, programming.

Check it out. If you want to learn some Ruby, just do this:

$ git clone https://github.com/edgecase/ruby_koans.git
$ cd ruby_koans
$ rake

You’ll get this:

AboutAsserts#test_assert_truth has damaged your karma.

The Master says:
  You have not yet reached enlightenment.

The answers you seek...
  <false> is not true.

Please meditate on the following code:
  ./about_asserts.rb:10:in `test_assert_truth'
  path_to_enlightenment.rb:38:in `each_with_index'
  path_to_enlightenment.rb:38

mountains are merely mountains
your path thus far [X_________________________________________________] 0/274

Get it? If you check out the koans/about_asserts.rb file, line 10, you’ll see this:

  # We shall contemplate truth by testing reality, via asserts.
  def test_assert_truth
    assert false                # This should be true
  end

There are a bunch of these tests (274, at the time of this writing), and they’ll walk you through a bunch of things you’ll need to know if you want to program with Ruby.

This has sort of taken off as a meme, a GitHub search for ‘koans’ shows 92 repositories, most of which are variations on this idea for many different libraries and toolkits.

Not to rest on their laurels, edgecase has a variation of koans up too, ruby_koans_online. Yep. It’s a little sinatra App, that gives you a webpage that shows the koans and allows you to fill things in:

You can then hit a ‘meditate’ button and it’ll change them over from green to red. Fun! It’s still very much a work in progress, it seems: You can see the start of an error there about an ‘insecure operation.’ But otherwise, it’s mostly functional.

The post koans – a pattern for learning languages appeared first on The Changelog.

Now that the Mac App store is open, everyone is wondering what they can get away with. Apple has added some interesting restrictions that applications must be compiled with XCode. There are tons of languages for which this is not exactly normal, and so people have been curious to see what kinds of things will actually make it in. In particular, the Ruby community has been pretty excited about building apps with MacRuby, since it fits the bill.

Well, I just heard about another oddball case, and it’s been successful: Jinjing Wang created an application called ClippingDetector, and he’s made a GitHub repo showing how he did it. Now, this isn’t the code for the ClippingDetector app itself, it’s Apple’s famed Currency Converter example. However, it does show how to use XCode together with a custom Python script that makes all of the magic happen.

I’m excited to see all kinds of programming languages being used for desktop Mac development; while I enjoy Objective-C, sometimes it can be a bit unwieldy. It’s also cool to have a real, working example of something when you’re attempting to do something new and interesting.

[Source on GitHub] [README]

The post Using Haskell to make a Mac App Store App appeared first on The Changelog.