HNHacker News
TopNewBestAskShowJobs

kalecserk

59 karma · joined April 22, 2018

submissionscomments
kalecserk··on Ask HN: What are the best programming tricks you know?
I also recommend this! I usually use the error handling of the language of choice for that purpose and implement the entire functionality returning errors/throwing Exceptions for the not implemented parts, and asserting upon in on unit tests to implement each pending functionality. I write the description on the assert message itself.

Edit: example

     use Psr\Http\Message\ResponseInterface;
    use Psr\Http\Message\ServerRequestInterface;

    class TransferHandler extends BaseHandler {

      public function __construct(Generator $faker, DataStorage $storage) {
       parent::__construct($faker, $storage);
      }

      public function handle(ServerRequestInterface $http_request): ResponseInterface {
       $resource_token = $http_request->getHeader('X-Resource-Token')[0];
       $account_id = $this->storage->account_id_by_resource_token[$resource_token];
       if (empty($account_id)) {
        return $this->responseInvalidResourceToken($http_request);
       }

       throw new \Exception('WIP -> store transaction data here for subsequent query, also issue notification');
      }
     }
With the following test:

public function testTransfer() { $juno = JunoAPISimulator::initialize($this->faker); $repo = AccountCreationRepoResolver::resolve();

     $account_id = $this->createAccountAndGetId(
      $this->merchant,
      fn(DigitalAccountRequestOperator $op) => $op->withProvider(DigitalAccountProviderSelector::JUNO())
     );

     try {
      Executor::execute(new IssueTransferByBankDetails(
       $account_id->toHex(),
       "BRL 12.42",
       $_ispb = '21018182',
       $_agencyNumber = '0001',
       $_accountNumber = '10000368021',
       $_accountType = 'CHECKING',
      ));
      $this->fail('should have thrown exception');
     } catch (\Throwable $e) {
      $this->assertEquals('WIP -> store transaction data here for subsequent query, also issue notification', $e->getPrevious()->getMessage());
     }
  }
kalecserk··on Everyone is still terrible at creating software at scale
I have been working with software development over the last 20 years and agree with that point of view 100%. Software development is the act of learning/researching. The source code we create is not a “product”. I really liked your metaphor of the research institute. Spot-on. Thanks for sharing
kalecserk··on Ask HN: Suggestions for books about API design?
The most influential technical book I have read over the past 10 years for sure. The author guides the reader though the process of managing complexity with some intriguing concepts such as "Define errors out of existence" and "Deep modules". I definitely recommend it.
kalecserk··on Don't trust default timeouts
I work on the payments industry and this issue has struk our systems several times. One extra piece of advice is to also consider the compound timeout when there are multiple calls to the same service. I still remember having our system comopletely hang because Rabbitmq was unresponsive. We had a 50ms timeout with Rabbitmq, but that didn’t protect us since we would hit the service 50 times per request.
kalecserk··on I found and fixed a bug in PHP's standard library
Humble and didactic, totally agree that we should thank the author. I for one felt compelled to contribute to OS after reading the article.
kalecserk··on Grail Demo from CHM Tape: Visual programming in the 1960s [video]
In a sense, this was a prelude of the modern day IDE. Allowing one to have a bird’s eye view of the project and helping with coding. Loved it!
kalecserk··on 25 Years of PHP [video]
There is literally a slide titled: `What was we thinking` where Rasmus goes through the most controversial decisions he made while doing PHP. I recommend this talk for anyone, specially because most of us, if we are lucky, will have to deal with a 25 year system at some time during our career.
kalecserk··on Technical Debt
Great comment, if you allow I would summarize by rephrasing one sentence making it shorter:

What you have instead is knowledge debt as engineers turn over, and the once intuitive and elegant parts of the codebase are utterly alien to the new hires who learned their craft in a totally different way. This isn’t tech debt because engineers can’t intuitively anticipate the business’s future.

That is it! Thank you for sharing your thoughts.

kalecserk··on The Use of assert() in SQLite
> In SQLite, the presence of assert(X) means that the developers have a proof that X is always true.

Almost impossible to prove anything in a sufficiently complex system such as SQLite. The difference between assert and always seems arbitrary IMHO

kalecserk··on Ask HN: Top three questions for a startup before accepting a job offer?
Great questions. Those will raise the interviewer’s perception about you as well. Source: am hiring manager.
kalecserk··on Ask HN: 40+ Career Advice?
I live in Brazil, we have a special kind of high school that will teach you a craft in addition to your tipical scientific preparation. And Yes, I have graduated from college, studied at night ;)
kalecserk··on Ask HN: 40+ Career Advice?
Hello!

I am currently 36, working for pay as a software developer since 1999, father of three -- and I would like to reiterate oppositelock's comment: "you're being too picky"

I totally understand your frustration with all this "helping other people" buzz but... Ultimately this is the job to be done by you right now :)

About the entire open-office culture, since I am a manager I have been granted a private office - which I have immediately converted into a shared quiet space to work for whoever might need it. I actually prefer to be where things get done.

I really think the problem lies in the engineering culture and maturity of the teams you had the chance to work with. Keep on looking!

Best,

kalecserk··on Uber Scam in Brazil – Drivers Have ‘Challenges’ Ending Trips
Pretty sure it will get you banned from their services. Source: work with payment systems
kalecserk··on Software Testing Anti-patterns
Cheers for bringing me back memories of “Spike solution” from the early 2000s :)

http://wiki.c2.com/?SpikeSolution

kalecserk··on Software Testing Anti-patterns
Totally agree, and this misinterpretation got crystallized into your tools that often recommend/generate tests that are named TestSubjectClassNameTest->eachMethodTest. We have to pay attention to that ;)
kalecserk··on Software Testing Anti-patterns
I have been working with teams that heavily use automated tests for over 16 years now and, at least on my experience, making others test your code would lead to untestable code and delegation of responsibility.

Even for manual tests, the test spec should make part of the change request and be reviewed appropriately.

Cheers!

kalecserk··on Software Testing Anti-patterns
> I start with the lowest-level, simple operations. I then build in layers on top of the prior layers.

I was discussing this with a coleague this week: starting by the lower level details vs starting from the more abstract/whole api. I prefer to start by writing a final API candidate and its integration tests and only write/derive specific lower level components/unit tests as they become required to advance on the integration test. My criticism on starting with the bottom-up is that you may end up leaking implementation details in your tests and API because you already defined how the low level components work. I have even seen cases where the developer end up making the public API more complex than necessary due to the nature of the low level components he has written. Food for thought!