nartz

Partially correct, but not necessarily true. Speaking extremely high level, the model is currently trained to fill in the blank space with something like the most probable options per pixels, based on the training set data. However, it is conceivable that it could be trained to also, say, insert an object into a scene, based on other characteristics found in the scene. Inotherwords, it could be trained to maximize a joint goal, where the second goal involved generating an object.

I think their whole approach was off - why even have warehouses, custom packaging, etc? Why not charge what it actually costs to ship something, plus a little more?

All they need is a bunch of vans that drive around and have a bunch of boxes and tape, basically ubers. They show up, package my thing up, and take it to the closest fedex store - enough said.

No custom boxes needed. No warehousing.

Is stashing an issue?

This is pretty cool. Although, on large codebases a la facebook or google size, I would think having a copy of the repo per branch might be intractable - also, somewhat unnecessary since one can just switch branches...

How many positions were you actually hiring for though?

No, it sounds like they were hiring for 3 positions, so they only chose 3.

They have a good product, no doubt - also interesting that "Box" stock has dropped some as of this hour.

However, to become the next giant, I would imagine they need to branch out and gain traction for tangential products. They've tried (dropbox paper) but not sure it has enough market share to make a dent just yet.

Sigh - its extremely naive to call "java" the issue. Every language, framework, OS, kernel (and frankly, even hardware) have their vulnerabilities. These types of comments sort of grind my gears.

If any google developers are out there - it would be great to be able to try this service out without having to type in a ton of information to get started - i just want to log in and see how it works - how it compares to IAM, auth0, etc.

what prevents ethereum mining on this if its free?

Another buzzword - this us simply pair programming but with 3 (or more) people? Frankly, I find working in this way to work but in an extremely inefficient manner. A simple code review is often much more insightful, more efficient, and easier to communicate versus piling around a single keyboard - just some thoughts.

"I don’t doubt that there might be a few hotel executives that are willing to bet on this, and sign up at this very early stage at a discounted price, but contrary to the belief of many others, this is really unlikely, and it’s not worth spending too much effort on considering the expected return."

Not worth the expected return? This sounds like a case of you wanting 'instant gratification' and to be making huge amounts of money from the start, which is bogus. With a few customers you will:

1. Be getting the use cases, bugs, feedback directly from your customers

2. Show you can get some funding and are building something people will pay for (or if they drop you, you'll understand why)

3. Have numbers, knowledge, and customer referrals which will VASTLY help getting more customers. I.e. when you are in the sales pitch, saying "X hotels have been using this for a year, and have generated Y additional sales, and have learned Z metrics about their hotel guests" etc.

Some sensible ideas - however, I'm on the fence about this one: "Unhelpful behavior: asking engineers to solve problems they didn’t cause"

Generally, I agree with breaking out bugs or issues that are found 'along the way' into separate subtasks or tickets. However, often what happens is a ticket is thrown into the backlog and not addressed.

Because the developer has just touched the code, this is often the best time to refactor as its still fresh in the mind, and this creates a culture of constant improvement. Of course everything depends, in this case, the complexity of the fix is the main limiting factor.

We truly believe in Refactoring along the way instead of trying to break out tech debt stories separately.

Very cool - although hard to tell from the video that they were in danger.

This is a logical but too theoretical argument.

Counter-arguments: 1. Mining equipment is a sunk cost usually, so many will keep mining. Inotherwords, its easy to continue operations as normal versus trying to sell off all the equipment (at a loss?) Also, cloud mining contracts are locked in for a year or two, most cannot be cancelled, so mining continues regardless.

2. The difficulty may not actually decrease that much to have a huge impact on the profitability. It really depends on the magnitude of the mining drop-off.

ICOs are not necessarily fraud - are they outlawed in your country? Do you simply need to register them properly with any countries you decide to release your app in?

'Trust' is sort of mangled here: what it means is that you 'trust' a single company on the other side of the transaction that makes up their rules/regulations and has their own customer service department, etc, i.e. VISA or MASTERCARD, that you have to deal with, as well as middlemen (i.e. the company that maybe issues the card to you like a bank or otherwise). They have the power to change their rules, raise your rates, close your account, etc.

With the distributed system, essentially we are trying to hardcode all of the rules, so there isn't any wiggle room for fraud, or a single person changing the rules on you, etc.

The downside to this, is that it means that it essentially becomes goverened by the software devs (or controlling body) of the altcoin. However, it sort of protects the consumer a little more by making it harder for a single governing body to make singular changes, because they'll want everyone who runs a type of exchange for the coin to participate as well so as not to alienate the coin and userbase...

Another buzzword. All of these things already happen - I feel like this post would have been relevant in 2010.

Ha - the title is linkbait - the microbes were FROM earth, but they were 'sequenced' in space.

Its a good post - but it must be said: the CEO (and board?) fucked up hardcore. They let themselves be tempted by acquisition, and then didn't protect themselves or the team in negotiations.

". Your mentor takes one look and says "the service can't find the database - point it to localhost:8900." You wait until he/she steps away from the desk, and then you anxiously google what the hell they just said. You did some SQL in your databases class, but these people are using an eight-node Cassandra cluster "because we have too much data for postgreSQL.""

Very few "elite" colleges teach a software engineer this type of practical experience. I want to debunk your feeling that if you had gone to a higher ranked college, you mysteriously would have been taught every piece of tech out there - this is markedly false - there are so many technologies, it's very common to be completely new to at least one when starting a new job.

This is merely a sign that the company has a bad onboarding process. Although, I have to admit its happened to me at many companies as well - i believe some see it as a sink-or-swim right of passage. Even though it's stupid - it does (in a misguided way) set the tone and test if you have what it takes to be a software engineer, specifically, that you have a relentless grit to just 'figure it out'. Again, sort of stupid imho.

I don't have any strong feelings about this either way, but the main question in my head after reading this is:

- Are the differences SIGNIFICANT enough to support two (three?) different codebases? A lot of your points seem to be more about building in configurations/plugins versus a completely different (core) storage format. For instance, adding in separate plugins for different dictionary compressions, or being able to specify the block read size or schemes. I would just think you may be spending a lot of time reinventing 80% of the wheel and 20% on 'memory specific' functionality.

(I'm naively oversimplifying, but its something to think about).

I think this article is really helpful when deciding to use a nascent technology (Electron) in production- pretty cool you can create a desktop app with javascript, but at the same time, expect to do a lot of custom bug fixing and hope that there aren't issues in the core code (note: there always are) =D

I would be curious to know when "Bailey's + Coffee" became a thing (i.e. drinking it warm versus cold)

After reading this and a few other sentences, i came to the conclusion that this article was machine written and stopped reading.

For some reason the form lets you have 'negative' years of experience - is that a thing?

My opinion is extremely biased, but the article seems retarded to call these out as any reason why these people are not getting jobs - an author who doesn't know what they are talking about.

"DevOps" is not something you just "teach" to someone who knows 0 about writing software let alone how computers work. Most of these roles today require knowledge of at least a programming language like ruby (Chef), python (ansible), etc.

You dont 'teach' cloud computing either imho. Sure, you can point students to the Amazon CLIs or Web UI Console (or others). Maybe technologies like kubernetes or otherwise would be in this blanket 'cloud computing' (orchestration?) umbrella, but I would imagine very much outside the scope of a bootcamp.

Agile Methodologies? I mean really? Someone drank the koolaid. =D

"Our founder invested the initial capital in KANOA, which went primarily into market research and a feasibility study designed by a large engineering firm hired to develop the product."

Founder immediately outsourced basic research and development - suspect at best. Working with an established engineering firm may be a good choice at some point, but my guess is that costs were 10x what they should have been, especially in the early stages where the product was going through iterations, bug fixes, etc.

Why do people say it 'Cant be tracked'? Its a fully public ledger. I would think that it could be tracked much easier than dollars that remain liquid or laundered.

Kindly disagree. If a business has a need that is critical to the business, not hiring a person with technical experience to manage technical things is just a mistake (or the business being lazy). I dont understand the shying away from hiring a qualified individual here. The fact is, its 2017 and there actually are a fair amount of qualified technical managers who can communicate and fufill the role.

Many other comments have pointed out various analogies in other fields that reinforce this.