rasteau · HackerTrans

rasteau

no profile record

comments

6 ปีที่แล้วdiscuss

The trade off is not installing Little Snitch.

6 ปีที่แล้วdiscuss

No need to wonder. https://www.npr.org/2020/03/19/818327945/israel-begins-track...

"Prime Minister Benjamin Netanyahu ordered the country's Shin Bet domestic spy agency, usually tasked with monitoring Palestinian and Israeli extremists, to launch the cellphone surveillance. It locates people who could have the virus and messages them.

"Meanwhile, late Thursday Israel's Supreme Court stopped the police from using the data to enforce quarantines, which it had started doing. The court also said it could scrap the program unless it goes through parliament or if the country is put on a total lockdown."

6 ปีที่แล้วdiscuss

For most scenarios where estimates are asked of development, there's usually an alternative approach that will yield better results.

Cost-benefit analysis scenario:

Request: We need to know how long it will take to build X so we can decide if we want to build it.

Response: What is the maximum amount of time to build X, such that if it took any longer, you wouldn't have us build it?

Rationale: Estimating whether a project will be over/under a time given frame is more likely to be accurate than estimating a specific span of time.

Dependencies scenario:

Request: We need to know how long it will take to build X because marketing needs to know when to start preparing.

Response: What is the amount of time marketing needs to prepare?

Rationale: Estimating that development is some amount of time away from completing is more likely to be accurate than estimating the entire project.

----

Underlying most arguments for estimates from development is an unwillingness by those doing the asking to do their own estimation.

7 ปีที่แล้วdiscuss

I wonder if they were inspired by https://queue.acm.org/detail.cfm?id=3321612

7 ปีที่แล้วdiscuss

Regarding cybersnowflake's comment, I think this is relevant: https://en.wikipedia.org/wiki/Poe's_law

7 ปีที่แล้วdiscuss

> The algorithm is secondary to the user group.

Neither is secondary; both are essential to the socio-algorithmic evolutionary process.

The algorithms are intended to optimize toward some user group behaviour. As the user group's choices influence the behaviour of the algorithms, so too do the algorithms' choices influence the behaviour of the user group.

8 ปีที่แล้วdiscuss

Amen!

My last three companies were moving from a monolith to microservices. In every case, the rationale for the move was little more than "monolith development is slow, therefore microservices".

Unfortunately for all of them, the true reasons for the slow development was poor separation of concerns, insufficient and brittle tests, and years of accumulated hacky shortcuts to ship new features "faster".

The folks pushing the microservice panacea were "proven right" in that development was much faster... initially. Without years of cruft in their way, devs were able to churn out new stuff (after a significant time spent ramping up on infrastructure code).

Eventually, and in every case, the fundamental flaws resurfaced, this time increasing in severity now that changing the system often required multiple service changes. As well, a host of new kinds of problems emerged: distributed transactions, network failures, client/server versioning, debugging across services, etc.

I'm now a microservice skeptic. Whatever your solution, it should be at the same "level" as the problem. A massive change in technical architecture will not solve the accumulated cost of your poor engineering quality choices.

8 ปีที่แล้วdiscuss

>HTTP was initially designed for transfering static files and static data over potentially unauthenticated connections.

It may be more useful to view "transfering static files and static data over potentially unauthenticated connections" as the first application of HTTP. While there are parts of HTTP that are useful for static data transfer (e.g., Cache-Control), there are parts of HTTP that would have no relevance if that were the only use case (e.g., 409 Conflict).

>it's not suitable for handling complex dynamic data

I would agree that HTTP was not designed to support applications pushing data from server to client, but that is a communication directionality issue separate from the issue of whether the data itself is complex or dynamic.

8 ปีที่แล้วdiscuss

It's an issue with the responsive layout. If the window is wide enough the overlap goes away; narrow enough the TOC goes away.

8 ปีที่แล้วdiscuss

> what happens if two users modify different fields/properties of the same resource at the same time?

https://tools.ietf.org/html/rfc7231#section-6.5.8

   6.5.8.  409 Conflict

   The 409 (Conflict) status code indicates that the request could not
   be completed due to a conflict with the current state of the target
   resource.  This code is used in situations where the user might be
   able to resolve the conflict and resubmit the request.  The server
   SHOULD generate a payload that includes enough information for a user
   to recognize the source of the conflict.

   Conflicts are most likely to occur in response to a PUT request.  For
   example, if versioning were being used and the representation being
   PUT included changes to a resource that conflict with those made by
   an earlier (third-party) request, the origin server might use a 409
   response to indicate that it can't complete the request.  In this
   case, the response representation would likely contain information
   useful for merging the differences based on the revision history.

Conflict resolution is inherently a consequence of the application-specific semantics of a "conflict". If the notion of "conflict" exists -- i.e., it is not obviated by application design[1] -- then conflict resolution is pushed to the caller.

That said, it may be reasonable to develop reusable conflict resolution mechanisms for reusable definitions of "conflict", allowing for composition of separate concerns as needed. This seems preferable to inventing a new system that binds concerns together with a single, irrevocable notion of "conflict".

[1] Using PATCH does not obviate conflicts that the application design otherwise allows.

8 ปีที่แล้วdiscuss

What you describe could also be used to argue that prices are higher than they would be in a competitive market, i.e., that for the 30% ratio it's not that the numerator is too small, but that the denominator is too large.

8 ปีที่แล้วdiscuss

> an unreasonable number of independent codebases must have identical bugs

Entertaining[0] badpun’s skepticism, it is not necessary they have identical bugs, only that their bugs yield similarly biased results.

For example, if a significant number of bugs are identified by their affect on the results, then bugs contributing to “wrong” results might be more likely to be identified and fixed.

[0] In the Aristotelian sense.

8 ปีที่แล้วdiscuss

The electronic strip search machines are still optional; they'll (eventually) give you a pat down instead.

8 ปีที่แล้วdiscuss

Hitchens responds: https://www.youtube.com/watch?v=jyoOfRog1EM

8 ปีที่แล้วdiscuss

> 3) If I'm in a hurry and the author is available I grab them and do an over the shoulder review. You might be surprised how much time this saves.

One concern here is you may ask questions whose answers are then given to you, and you alone. If it's likely someone else in the future will have the same questions, the "answers" should be in the form of improved code.

> 4) Don't struggle with difficult sections of other people's code unless you have a vested interest in remembering this specific section of code. Ask about unclear areas.

I'm not clear on the distinction between "difficult sections" and "unclear areas"? Either way, one of the outcomes of the review should be to make life easier for the folks that follow us.

8 ปีที่แล้วdiscuss

Yikes! Demanding a bug fix also remediate unrelated, extant style violations is a good way to ensure nothing improves.

8 ปีที่แล้วdiscuss

I think the author and many folks here have an unhelpful understanding of code reviews.

I suggest code reviews' primary purpose should not be to catch bugs or trivial style issues; automated tests and linters exist for those purposes.

Instead, code reviews should be primarily thought of as "human comprehensibility tests".

When we write code, we've may have spent a significant amount of time thinking about the problem. This puts us in a bad position to gauge how readily someone in the future can reason about our code in order to fix or modify it safely and easily. Code reviews are a mechanism for showing empathy to our future selves, which accumulates over time into a much more pleasant coding environment.

Relatedly, comments on a PR are ephemeral. A rule of thumb I use: if a reviewer asks a reasonable question -- something someone in the future might wonder about when I'm no longer around, I answer it by first improving the code.

8 ปีที่แล้วdiscuss

"[T]he English language... becomes ugly and inaccurate because our thoughts are foolish, but the slovenliness of our language makes it easier for us to have foolish thoughts."

8 ปีที่แล้วdiscuss

> I frequently have a driver who is obviously different than the one pictured in the app.

Do you continue the ride? Do you inform the company?

> Talk about an industry that needs regulation!

I infer that you use Uber/Lyft/etc despite your concerns. Why not instead vote with your wallet, and use one of those nice, government-regulated taxicabs?

8 ปีที่แล้วdiscuss

>We need to get between grams and a count of molecules, that's the number.

I think that number is only true for carbon-12.

>but then we would have some other arbitrary constant we would have to memorize to go from grams to a count of molecules.

I think we already have to do that, hence molar mass.