Good Friday

Lately, I started reading the “Remote - Office not required” book by 37signals’ co founders. Similar to “Rework”; it’s a really interesting guide that you can always refer back to.

In the Forward motion chapter of the How to collaborate remotely section, if you hide the implementation details of remote working, you still end up with good advice:

To instill a sense of company cohesion and to share forward motion, everyone needs to feel that they’re in the loop.

In our team when we felt that the flow of information was running slowly through the office, we attempted to gave it a boost with 1~2 per 2~3 weeks team “gatherings”. Consider this event as the synch version of 37singals’ weekly discussion thread with topic “What have we been working on?”.

Everyone chimes in with a few lines about what they’ve done over the past week and what’s intended for the next week It’s not a precise rigorous estimation process, and it doesn’t attempt to deal with coordination. It simply aims to make everyone feel like they’re in the same galley and not their own little rowboat.

In terms of the authors, this is what our “Good Fridays” evening team gathering is all about. Product, customer support, developers have a discussion on the latest metrics, roadmap updates, what code was shipped and devop operations.

Simply put, progress is a joy best shared with coworkers.

PeoplePerHour team Good Friday

The Future of programming via @worrydream

It was really hard for me to realize where I could view the commit history of a git repository on github.com in 1 second, so I wasted more time. Finally, I got it, the number of commits link to the commit history, but it’s not that obvious if not obvious at all. I think what most of git users know as git log is more important than “eye candy” graphs/networks etc. What do you think?

When your API uses Oauth1.0

know no #fear #okeanos @grnet_gr

Thoughts on w̶̶e̶̶b̶ application development

“How you build your application, it is not the tools you use.”

This quote is result of discussions with other developers. Every time the “how you build your application?” question drops, I get answers like “we use $x framework”, “$y database” in some rare cases “we do tdd” is between the answers.

I will stand in the framework as it is considered to be main library to build your application. And since MVC is the monopoly out there

Model, View Controller.

Lets rethink about it for a minute, shall we?!

Model

There is a misconception that Active Record is the Model. So what is Active Record if not the model of the application:

The interface of an Active Record object would include functions such as Insert, Update, and Delete, plus properties that correspond more or less directly to the columns in the underlying database table.

Using an active record as you model, dominate the shape of your code. Now the persistence logic is all over your application code. In the case of an application a model would be a Beer object. If I asked you to create a Beer Class would you ever thought about a function name like save(), insert(). But your code is bloated and you end up having the database in the middle of your application, this make transition to other type of persistence more hard. There other patterns out there…

Before moving on a note on the Beer object we mentioned before. A Beer object has different values and functionality based on the place it belongs example: in the factory, during the transportation and finally at a bar.

Controller

Controller here is to define the context. Based of context he uses the appropriate models. Its use case, a scenario. Its not Create Read Update Delete. Who is talking to your application controller? A Mobile Client A Desktop Client A Web Client … a.k.a. a browser. Since we are talking about web let’s be clear about it. There is no such thing as a “user” in your application. Your web/mobile/desktop client may have a user but your application only accepts requests to do magic. Parameters of your request should state if the action should be done or not. /myBasket/view /basket/41491/view?customer_id=1943&secret=? The request and the result have 1-1 relation. The same url must always give the same result no matter what. Hints: Reverse caching. This same result should be predictable this mean your controller should be testable. It’s is an object in the of the day isn’t it ? And the http protocol it is just a detail.

View

Speaking of results, what a result could be except a representation of your application models in variety of states during their lifecircle. A view of your application should not contain html. Html is used by browser to render a web page. Your models data may appear on that page but they are not the page. You can always use XML if you like tags or if your web client needs to navigate with xpath. What is the tricky part in a view like more than encoding my objects to json? Your applications navigation. Your clients should be ignorant about your applications urls. Every response from your application should contain paths to related application calls the same way a web site provide links to related resources.

A really “interesting” finding from the youtube UI, is the “Show more” functionality for the video description. It is is triggered by clicking at any part of the “description box” ( blue box on the picture, div with id watch-descirption. Liked it, because since you realize it you don’t need to “target” that small part with your mouse cursor to trigger see the full video description. Hated it, because you could need 2 clicks if you need to access a link in the description.

Thank you #github for your edit file feature #shootTheMaster

Where is MyMoney at?!How!