HNHacker News
TopNewBestAskShowJobs

gtramont

138 karma · joined November 13, 2013

[ my public key: https://keybase.io/gtramontina; my proof: https://keybase.io/gtramontina/sigs/LKfQIT3YjaXRo6G2jVqVtMelBDHt81oOCfsHlikOJO4 ]
submissionscomments
gtramont··on The Rise and Contentious Fork of RSS
What a well written piece! Thank you for that!
gtramont··on Afraid of Makefiles? Don't be
Here's some tips I like to follow whenever writing Makefiles (I find them joyful to write): http://clarkgrubb.com/makefile-style-guide
gtramont··on Free Classic Books by MIT Press on Archive.org
Hard not to think of Aaron Swartz when reading something like this…
gtramont··on Split user stories ruthlessly and get value earlier
And Mike Cohn's SPIDR tips for splitting stories:

- https://pbs.twimg.com/media/DBuzze5XsAA2Zbt.jpg:large

gtramont··on Split user stories ruthlessly and get value earlier
Reminded me of Paul Hammant's posts:

- https://paulhammant.com/2012/04/24/call-to-arms-average-stor...

- https://paulhammant.com/2012/11/12/smaller-stories/

gtramont··on App sizes are out of control
For the developers out there, here's one option for native applications that leverages the beauty of the web: http://jasonette.com/
gtramont··on A day without JavaScript
> "(…) but I just can’t get down to less than 30 in any one window"

Just like me! I also suffer from the same disease, but on a much more serious level… lol! Everything just crashed yesterday and the count was on 270+… :-o

gtramont··on JSON Feed
This is exactly one of the things that media-types solve. Simply using application/json doesn't tell me (consumer) anything about the semantics of what I'm reading. It only tells me what "parser" to use. If we have a proper media-type, like application/hal+json, I know exactly how to create a client for that type: I need to use a JSON parser _and_ use the vocabulary defined by HAL…
gtramont··on SpiderOakONE – Zero Knowledge Cloud Storage
Just wanted to drop a note here… I've been a long time user of SpiderOak and am really satisfied with it. A much better alternative to Dropbox and alikes.
gtramont··on Ask HN: How can I become a proper Project Manager from a Programmer?
Totally agree! I guess this is the point I tried to make. :)
gtramont··on REST Anti-patterns
This doesn't really matter. What you'll end up exposing via your API is your use case! Does your system allow for an account to be closed? Awesome! So let the client know how to do it.

If you're speaking HTML it can be as simple as:

  <form action="/close-account?acc_number=12345" method="POST">
    <button>Close Account</button>
  </form>
Or even:

  <form action="/close-account" method="POST">
    <input type="hidden" name="acc_number" value="12345">
    <button>Close Account</button>
  </form>
If you're speaking Siren (https://github.com/kevinswiber/siren):

  {
    "actions": [
      {
        "title": "Close Account",
        "method": "POST",
        "href": "/close-account",
        "type": "application/x-www-form-urlencoded",
        "fields": [
          { "name": "acc_number", "type": "hidden", "value": "12345" }
        ]
      }
    ]
  }
gtramont··on Ask HN: How can I become a proper Project Manager from a Programmer?
My only advice is to not simply jump into a management role because it is the only career path you see. You can still be technical and progress your career! I definitely encourage you to try and experiment different roles, though, as this brings you versatility and understanding the lifecycle of a project.
gtramont··on Crystal: Fast as C, Slick as Ruby
And it already got a port of Sidekiq: https://github.com/mperham/sidekiq.cr
gtramont··on Self-Documented Makefile
I usually escape regardless... But you made a good point about the single character directory. The target name can be anything that makes sense, anyway... `make help` as suggested previously.
gtramont··on Self-Documented Makefile
This is basically how I've been doing for quite some time now. `make ?` Check it out here: https://github.com/gtramontina/sourcing/blob/master/Makefile...
gtramont··on TTNT: Test This, Not That
These are all remedies for the symptoms. The actual disease, which is considering the framework part of your core business application, remains.

Decoupling from your persistence (and presentation, fwiw) brings a lot of benefits, not only faster tests. I'm sick of people saying "why introduce a layer here if we'll never change the database?". The answer is simple: yes, you will change the database, specially when testing where you want to plug an in-memory store.

Again, I get that Rails gives us conventions so we don't keep bikeshedding, but how often do we challenge these conventions? How often do we question whether the problem we're solving fits the CRUD/MVC patterns?

gtramont··on How we took our tests from 100 seconds to 100ms
That is probably on a CI server. During development, I'd probably be running way more than that, at every production or test line written, having a task that watches for file changes and re-runs all tests. Then, having a fast test suite is key.

While speeding up the process is always good, tools like lucifer or spork are only masking the problem: loading the whole environment for unit-level tests. Sails, like Rails, promote tight coupling between all parts of the system, which harms test speed, thus harming another development tool: TDD.

The more decoupled and isolated you write your business logic, the easier and faster it is to test drive it. Then you simply plug an HTTP interface (with routes and whatnot) that calls into your core.

gtramont··on An API is only as good as its documentation
Please educate me (and everyone else reading). What is incorrect?
gtramont··on An API is only as good as its documentation
It is not "personal definition". And I have shared it… just follow the link I posted earlier.
gtramont··on An API is only as good as its documentation
My premise was, when I wrote the first post, that REST is understood. Not a surprise that it is not…

I totally agree with you… And what I've been trying to do to whoever I talk to, in my team and outside, is to educate them in this area (sending resources like I did on an earlier post), and try to make them not call any json-based API REST (which in fact has nothing to do with json specifically).

gtramont··on An API is only as good as its documentation
So you don't know what REST is (and didn't read the link I posted earlier).
gtramont··on An API is only as good as its documentation
Did you read what I posted? If you're writing a REST API (I advise you to read http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hyperte... if you think you know what REST is) then all you need is an entry point (much like http://news.ycombinator.com) then everything else should be hypertext driven.
gtramont··on An API is only as good as its documentation
It all depends on what kind of API you're building. If you're implementing a RESTful API, no documentation is needed, as it is "surfable" due to the use of hyperlinks. If you're implemeting an RPC API (which is what most of us are doing), good and up-to-date documentation is key, as we need to document each and every meaningful end-point.
gtramont··on We have broken HTTP
Absolutely. If you ever used a web browser (one that understands HTTP and HTML), clicked a link on any website, or submitted a form, you've most likely benefited from REST. Here's an example: https://news.ycombinator.com
gtramont··on We have broken HTTP
REST has nothing to do with JSON. How dare you saying that no-one uses while you're using the world wide web every single day?
gtramont··on We have broken HTTP
Perhaps if people understood better the technology that allows their business to operate, they wouldn't waste time versioning APIs and having to re-write clients (web, mobile...) every time the server changes something!
gtramont··on We have broken HTTP
HTML is a hypermedia format. REST is an architectural style that requires hypermedia in order to work. Hypermedia formats have factors (http://amundsen.com/hypermedia/hfactor/) that make them more suitable for some use cases and less suitable for others. HTML alone does not have idempotent updates (PUT, DELETE), but as REST allows for "Code-On-Demand", we can augment the user experience with Javascript, and it allows PUT/DELETE (with XMLHttpRequest).
gtramont··on Show HN: A virtual whiteboard for working or teaching remotely
Totally experimental, by the way...
gtramont··on Show HN: A virtual whiteboard for working or teaching remotely
Back in 2011, when I was starting with node.js I built something I called 'Writeboard' https://github.com/gtramontina/Writeboard . It's not an active project anymore, but I've considered resuming working on it. A rewrite of it is hosted in heroku, at http://writeboard2.herokuapp.com/ -- Check it out.
gtramont··on The Ultimate Frontend Build tool: make
Here: https://coderwall.com/p/aawcnq My point is at not having to install dependencies globally. And keep the benefits of tools like gulp/grunt...
← PreviousPage 2 of 3Next →