elomar

leiloando meus livros com ajuda do twitter

Pra juntar uma grana prum macbook, decidi leiloar 15 livros. Com ajuda do pessoal no twitter e uma pitadinha de competição, o leilão superou em muito as minhas expectativas :)

Esperando vender alguns pros meus colegas aqui de natal e doar o resto, coloquei um leilão no ar e avisei no twitter.

De repente - BAM! :) Muitos amigos retwittaram e os lances começaram a chegar. Em pouco tempo todos os livros já tinham lance. Continuei divulgando durante a semana, e sempre que eu divulgava a galera ajudava retwittando e mais lances apareciam. Twitter = WIN.

Cairo Noleto deu a idéia, e o dono de um livro começou a receber um email sempre que o lance dele era coberto. Isso facilitou a vida de quem queria o livro e ajudou a esquentar o leilão. Maior diversão era ver duas pessoas disputando um livro lance por lance :) Competição = WIN.

No fim o leilão foi bem bem melhor que eu esperava. Ficou no ar uma semana e todos os livros foram vendidos - alguns com lance maior que o valor na amazon - e o total foi bem maior que o que eu achava. Obrigado a todo mundo que deu lance e divulgou no twitter :)

Tudo isso foi feito sem nenhum conhecimento de social whatever ou vendas, e por isso tenho certeza que devo ter escorregado muito. O que você acha que eu podia ter feito pra conseguir mais/maiores lances?

Ah, gostou da idéia e quer fazer um leilão também? Manda um email pra elomar@maisweb.org.

ps nerd:

A aplicação é feita em sinatra + mongodb, heroku + addon pro mongohq, e usa uma pitada de google app engine pra mandar os emails em background - tudo free.

rubysoc, daily digest 06/08

Today I finished a proposal for a nicer ActiveResource API. To get to that I read the documentation of some restful-like apis (like flickr, google data apis and sun cloud) looking for things I would need to make a nice client to them and asked my mentor and some other rubysts for feedback. Now I’m going to make it work :)

On the non-rubysoc side I made a little sinatra app to sell my books. It’s hosted on heroku, uses mongodb for data and appengine for cron tasks. I also got my welcome pack from Roane State College, where I’m going to study for a year. It turns out I’m going to live in Oak Ridge, a city created to project manhattan and that hosts the world fastest supercomputer (and where Megan Fox was born). Nice! :)

rubysoc, daily digest 06/02

Today I got association retrieval though atom links working!

With the links structure in place, I think it will be easy to achieve my next goals: the CRUD operations working through links and then it all again with XML and JSON. Tomorrow I’ll start working towards that and start reading the Atom spec to clarify how some things should work.

Today I also - finally! - got completely rid of an old freelance job. yeah! :)

rubysoc, daily digest 05/31

After an offline weekend, energies renewed :)

Today was the better day until now - and tomorrow will be better :). I helped the restfulie team to get restfulie working on ruby1.9 and added basic atom serialization/deserialization to active resource. Doesn’t seem like much, but these tasks weren’t that easy to me :)

Tomorrow I intend to work on adding links to associations.

Oh, and last Sunday there was an barbecue for the fulbright scholars from Natal to socialize. It was awesome, the fulbright guys are awesome, going to the usa is going to be super-duper-awesome :)

rubysoc, daily digest 05/27

Today I didn’t get a lot done :(

The only worth noting things are setting up a rubysoc project on basecamp and making restfulie 1.9 compatible (hope they apply the patch I send :)

And on the not worth noting things, I finished Portal. Damn you, steam and you free games!

rubysoc, daily digest 05/26

Today I talked with José Valim, my primary mentor, about my initial goals. We decided that it would be better to start by improving ActiveResource with all the good stuff from Restfulie. My first milestones will be:

• Make ARes send and receive Atom
• Make associations work using links. This will be done first with Atom, where we already know how to make links. Later on this will be added to xml and json, but we still need to decide a good way to do it (maybe xlink or Link headers)
• Make ARes use URIs along with (or instead of) ids

On the side I’ll be working on improving Restfulie. The first thing I want to do is make it ruby1.9 compatible.

Now to what I did today:

• Got my first patch into rails (thanks, Valim! :). Gosh, they’re letting anyone do it these days ;)
• Got associations working in ARes though xlinks. Most of this code will be thrown away because I’ll start with Atom and it’s a little “hacky”, but doing it made me understand ares internals better and see how I can handle associations.
• Started to work towards making Restfulie 1.9 compatible. I got the tests to runbut there are some still failing, most of them thanks to some extensions to the Ruby core. Tomorrow I’ll see if these extensions can be replaced with something simpler or how I can make them to work with 1.9

Ah, and I finally watched lost finale. I can’t say I didn’t like it, but I really would prefer a more sci-fi and less spiritual ending. 

rubysoc, daily digest 05/25

Today was a really bad day :/ Early afternoon I wasn’t really like coding so I decided to watch Writing Modular Ruby Code: Lessons Learned from Rails 3 while organizing my stuff (my desk was a complete mess). Then I blowed up my mac messing with system files (not: read the red alerts).

Well, enough with boring excuses. Today I:

• merged my restfulie fork with master, but nothing is working yet
• read the ActiveResource code and noted some things to improve
• discovered this restfulie manual by caelum. I’m trying to go through it, but some things aren’t working on 1.9.2. Going to take a deeper look at them tomorrow.

That’s pretty much it. Tomorrow I’ll try to do more and focus on my first goal: navigate ARecord associations with AResource.

rubysoc, daily digest 05/24

Today was more of an “exploration” day. I set out to take a look and try a bunch of http related ruby libs and see what I could learn from them. Some things that I thought very interesting:

• patron is an http client based on libcurl. It can be used to replace Net::HTTP, and is ~2x faster in most benchmarks.
• excon does http in ruby with raw sockets, and keeps the connection open. You can take a look to see how http works.
• faraday is an http library heavily inspired by rack. The way it uses adapters and middlewares is very interesting. Comes with adapters to Net::HTTP, patron and typhoeus.
• mechanize let’s you automate web browsing. It isn’t very related to my project but I is a very useful tool to know about. I think I’ll be using stay up to date with my tv series :)

I also took a better look at caching (client side caching, advanced http caching, How HTTP Already Solved All Your Performance Problems 10 Years Ago, caching tutorial), got to know the PATCH http verb and found a little ActiveResource bug when playing with it.

Ah, and it feels great to come back home after the classes, after all these years :)

Architectural Styles and the Design of Network-based Software Architectures, chapter 4

These are my notes on the fourth chapter of Roy Fielding’s paper on Architectural Styles and the Design of Network-based Software Architectures, “Designing the web architecture: Problems and Insights”.

In this chapter we develop an architectural style that could be used to guide the design of improvements for the modern Web architecture.

The web should be a place where people could store and structure their own information, in a way that it could be used by itself and others. This content should be provided and consumed by a very heterogeneous collection of devices. A universally consistent interface to this information should be available on many platforms as possible.

Since participation was voluntary, the entry barrier should be low. Hypermedia was chosen as the user interface because of it’s simplicity and generality, with the added ability of performing simple queries by providing user-entered data to services. Partial availability must not prevent the authoring of content.

The web should also be extensible and prepared for change, to avoid getting stuck with limitations from the present.

The web is based on distributed hypermedia, which

is defined by the presence of application control information embedded within, or as a layer above, the presentation of information. Distributed hypermedia allows the presentation and control information to be stored at remote locations.

It’s architecture must, therefore, be designed for large-grain data transfer. The architecture need to minimize network interactions in order to, for example, improve user-perceived latency.

The web is intended to be an Internet-scale distributed hypermedia system. Architectural elements need to continue operating when subjected to unanticipated load or when given malformed data. Suppliers should be prepared for gradual and fragmental change.

The initial web protocols were designed for single request-response pairs. The deployed architecture had significant limitations in its support for extensibility, shared caching, and intermediaries. Working groups were formed to work on the three primary web standards: URI, HTTP, HTML.

The first step was to identify the constraints placed on the early web that are responsible for its desirable properties. Additional constraints can be applied to an architectural style in order to extend the set of properties induced on instantiated architectures.

The next chapter introduces and elaborates the Representational State Transfer (REST) architectural style for distributed hypermedia systems, as it has been developed to represent the model for how the modern Web should work. REST emphasizes scalability of component interactions, generality of interfaces, independent deployment of components, and intermediary components.

Architectural Styles and the Design of Network-based Software Architectures, chapter 3

These are my notes on the third chapter of Roy Fielding’s paper on Architectural Styles and the Design of Network-based Software Architectures.

The purpose of building software is not to create a specific topology of interactions or use a particular component type — it is to create a system that meets or exceeds the application needs.

This chapter presents a representative sample of architectural styles, analyzing their advantages and disadvantages when applied to a network-based hypermedia system.

Below is a summary of the styles presented. See their complete analysis at the dissertation.

These are the ones I thought more interesting:

Uniform Pipe and Filter (UPF)

Each component (filter) reads streams of input data and produces streams of outputs, usually while applying a transformation. Each filter must be completely independent of other filters. As the system is just a composition of filters, it’s simple to understand. PF supports reuse by allowing any two filters to be hooked together if they agree on the data being transmitted between them. All filters must have the same interface. The Unix shell is an example of this style.

Cache ($)

Is the replication of the result of an individual request such that it may be used by later requests. Provides improvements on user-perceived performance and scalability, since less requests are made through the network.

Layered-Client-Server (LCS)

A client sends a request to a server, the server sends responses back. The layers between them add proxy and gateway components. Each layer provides services to the layer above and use services of the layer below.

Client-Stateless-Server (CSS)

Derives from the client server style with the additional constraint that no session state is allowed on the server component. Session is kept entirely on the client, and each request must contain all the information required to be understood by the server.

Layered-Client-Cache-Stateless-Server (LC$SS)

Take LCS and CSS and add cache to the mixture.

Remote Data Access

Client-server variant that spreads state across both client and server. The client sends a query to the server in an standard format (such as SQL), the server performs it. The client must know about the data structures in the server.

Code on Demand

The client has access to a set of resources but don’t know how to process them. It sends an request to the server for the processing code and executes it locally.

Layered-Code-on-Demand-Client-Cache-Stateless-Server (LCODC$SS)

Add Code on Demand to the LC$SS discussed above by treating the code an just another data element. One example is the HotJava [http://java.sun.com/products/archive/hotjava/] web browser, which allows applets and protocol extensions to be downloaded as typed media.

Event-based integration

A component broadcast one or more events. Other components can register interest in that type of event and be invoked when they occur. Advantages include strong support for extensibility though the ease of adding new components that listen to events and the removal of the need for polling the server. The main cons are the single point of failure in the notification delivery system and the susceptibility to event storms.

Brokered Distributed Objects

The system is organized as a set of objects - each with it’s own state and behavior - interacting as peers, with name resolver components. CORBA is one example.

Now that we understand what are and how to evaluate software architecture styles, we’ll get into the web. In Chapter 4 we’ll evaluate an architectural style to guide the design of improvements for the modern World Wide Web architecture.