qyv

Do people honestly use FB to keep up with what others are doing? IMO it seems like the primary use-case is to let everyone else know about what you are doing.

I wonder how that guarantee will be realized? Subsidies? Unless I am missing something, this seems to be artificially lower operating costs of the Semi in order to make to favorable to diesel.

It is a vocal minority in the (probably correct) assumption that the majority of Go programmers are not part of that GitHub issue, nor any other group asking for Generics.

> I can no longer focus. I am constantly pulled into meetings.

If this behavior changes solely because you start working remotely it may not necessarily be to your advantage. Yes, in the short term you may maintain the ability to focus. However, in the long term you may find yourself being excluded and and diminished within the organization. These meetings, etc. don't stop when you work remotely, only those attending them do.

One key difference being that, when you see people every day, it is much easier to measure, manage and mitigate this behavior.

If you read the link these rules only apply to labeling for anything marked as a "Meal Replacement" product, like soylent.

I think the issue is that the new keyboard is turning out to be significantly less reliable than the previous generation. No keyboard should require cleaning with compressed air after only a few months of normal usage, that is simply poor design.

Regardless of the extensive science behind computer programming, I still consider programming a "creative" field. Yes, you do need sound engineering and be able to at least have a working understand some of the computer-science, but there is more to it than that. It also requires the creative ability, just like painting a picture or writing a novel. You need to be able to conjure ideas and take them from theoretical manifestations to concrete implementations. You need to be able to look at a problem and see the way to the solution, like a sculptor can look at a chunk of rock and see a statue.

His dismissiveness of other languages is startling given the topic of this talk. The first step in learning is realizing that you don't know everything. To me the COBOL example is the most telling, he literally says there is nothing to learn from COBOL.

I don't know for sure, but I would think that there is likely some kind of difficulty in sending high-speed signalling through a magentic field like that. I think there was a reason Apple only ever used magsafe for power.

It's funny how we have been trained into thinking a product is sub-par because the team didn't spend a lot of money on marketing material.

> but that booking a ride costs Uber pennies. Their share of the ride revenues is dollars. How is that not going to be super profitable once new market development costs ramp down?

Yes, booking the ride costs pennies, but actually providing the ride costs them dollars. The question is how many dollars do they need to charge customers and pay drivers to maintain them both, and whether that calculation leaves Uber (or any other of these services) any profit. This is where the 'low barrier to entry' argument comes into play; it is so easy to enter this market combined with the fact that both drivers and customers can (and already do) swap to the service with the best financial benefit to themselves. It remains to be seen what the steady state of this equation is.

Does best mean "highest" or "most accurate"?

I think the point is if you have to trust someone then using a blockchain is no better than using centralized ledgers.

I wonder how many people make this exact mistake.

It is also interesting that the thefts seem to stop after they moved to the new wallet software.

The point of the article is that Go and Rust don't actually serve the same purpose. So asking "Go or Rust" 99% of the time means choose Go. For the other 1% of the time you (should) know that you actually need Rust, not Go.

> This is how it works at almost every company. Call it horrible if you want, but everyone stops short of describing in detail the exact architectural replacement. And when someone does, it inevitably has flaws that make it impossible to meet business goals.

No, it's not how almost every company works, and yes it IS horrible. Do you know why people stop short of giving details of what should have been done? Because that is a full time job for a entire team of people in any place that needs real security, and part of that job is to be constantly rooting out flaws in both design and implementation and fixing them. And guess what, if your business involves storing and retrieving sensitive personal information on millions of people, then security needs to be one of your business goals. If it is not, then that is negligent.

> It's too easy to handwave this away as "well, get a better architecture." Everyone knows that; the hard part is, what architecture? How does your architecture work in practice?

It is also easy to handwave away the real work that real security professionals do. Security is not a just some module you can strap into your systems, it is an ongoing process that requires vigilance and competence. Yes it is hard, but being hard is not an excuse

> Encrypting items won't help when the keys need to be stored in the same place to access the data. The attackers will just go after that box instead of the DB. You can guard it more carefully, but the point is that some box somewhere needs access to a substantial amount of the data at any given time. It's the nature of a credit bureau.

So you are implying that data encryption is not useful for protecting sensitive data because you have to store the keys somewhere. If that were the case then data encryption in general would be useless, we know that is not the case. This is a design or implementation problem, not an encryption problem.

Agreed, I do Ruby development like this and it is seemless. The code, editor and git live on Windows while Ruby and MySQL run on wsl.

I disagree, microservices can offer many distinct benefits over a monolith. Yes, fine-grained scalability is a huge benefit, but there are many other advantages as well. I was going to list a bunch but honestly they can be found on google quite easily. More importantly though, is what I think is the key to making microservices deliver on their promises: Well defined and designed API's.

Designing good API's is important for all software, but is critical to making microservices work well; and it is not always obvious how to do this well. I can understand why so many people say you should start with a monolith and then break it up into microservices: With the monolith you have already accumulated a ton of domain knowledge so you can break apart the service-boundaries much easier. However, it can still be tricky to do this because not ever module in your monolith should be a service, infact it is likely that most will not. Microservices are a different level of encapsulation than a module. Sometimes microservices should done one thing well and with authority, sometimes they should do many things within the same domain/context, sometimes they should do an entire class of things to their data source, etc. Designing good API's forces you to understand how execution and data will flow through your system and how you can effectively and cleanly delineate between them.

IMO, the most important thing for a microservice, regardless of its size, complexity or role within your system, is it's API. When you have a well defined API you can encapsulate and abstract that entire service from the rest of your system, which is a wonderful thing. This microservice can now be deployed, updated, scaled, refactored or even rewritten entirely without any of the other services in the system even noticing. It brings a tremendous amount of freedom to managing your software platform. You no longer need to worry about things that don't concern your service, just fulfill your APIs and life is good!

You should not need to do this with microservices. Part of creating them is implementing well-defined API's, which create concrete borders between your services. It is extremely easy to capture/log all traffic passing between your services, which you should be able to use to determine which service is misbehaving, and them aim your debugger there. If you cannot do this, then your API's are not doing what they are supposed to be doing.

How does a self driving car differentiate between a police officer flagging you down and a carjacker? Humans can make this judgement because we have a context for each of those situations based on our understanding of how the world works outside of just operating a vehicle safely.

The exceptional cases can often be the most important, especially when you are talking about moving humans from place to place. I wonder how a self-driving car would react to something like driving in a hurricane?

Isn't that kind of the point though? Yes, computers can hear better than humans, but they fail miserably at understanding the meaning of what they are hearing and responding with the appropriate actions. This is exactly the same issue that is/will be faced with self driving/driverless cars.

> it's a Fortran or Cobol situation, only maybe three or four orders of magnitudes bigger.

You underestimate the amount of COBOL code that is still out there running our daily lives:

http://collaboration.cmc.ec.gc.ca/science/rpn/biblio/ddj/Web...

This is extremely disingenuous of them to have their FAQ essentially contradict their TOS. Honestly sounds like they are deliberately trying to deceive people.

Apple is free to this move for business reasons, that is certainly true. But they can no longer also claim the moral high ground as a defender of personal liberty. Human rights do not stop at international borders. They cannot have it both ways.

FYI: Don't use the killer drivers, let windows install it's own driver.

To offer a counter point: I dislike the idea of "I write generic code". I say this because it is one of the prime calling-cards of the over-abstraction, which IMO is one of the biggest (and most harmful) self-inflicted injuries in programming right now.

Honestly, IMO, 9 times out of 10 the places that developers use templated-types in order to "write generic code", it is an over-abstraction. The generics end up adding nothing but source-code complexity. I often wonder if the only reason generics get used in some situations is because the standard lib uses them.

> there must be some other mechanism for establishing that the behavior of the contract matches the common understanding of what the contract does.

There is, we have been using them for hundreds of years, it is called a contract.