pinkgodzilla

In develop mode, hot module reload (HMR) changes the text immediately on the screen as you edit. But yes, HMR and caching has some glitching once in a while.

I tried Hugo, Jekyll and Gatsby. Assuming that a static site is 95% likely a marketing (self, company or otherwise) site and a marketing site needs to impress, a static site generator should be first and foremost built from the requirements of frontend and not leave the user to "theme" some default HTML.

Gatsby is ridiculously fast (React based) and its plugin universe is full of all the common features you could ever need. It has built in 1-click service workers plugin for offline access, 1-click plugins for prefetching links you put on your page, auto-inlined-css (in v2), all kinds of markdown + fringe requirements like LaTex, video embedding, things like Call to Action plugins, MailChimp sign-up-here plugins etc. To get a feeling of the snappiness, check out their landing at https://www.gatsbyjs.org/ and their plugins here: https://www.gatsbyjs.org/plugins/ .

The community pushes and PRs at break neck speed every day and is super friendly - can definitely get the support you need. Lastly, it is a great way to "inverse learn React" if the objection is "Wow, I don't know enough React". React by itself is not that opinionated and Gatsby has enough good practices of putting together a React framework for you to use productively.

ps: the other frontend alternative would be vuepress, it should feel blazing fast too. Here's another article on why speed is so important: https://www.gatsbyjs.org/blog/2017-09-13-why-is-gatsby-so-fa...

If this occurred frequently for my business, you would architect your system for on-prem flexibility and capabilities. However, I think for just "data" like S3 blob storage, this is definitely a no brainer. I would imagine for VMs its going to be a lot more difficult with load balancing, permissions and what not.

They never change over the course of say 3 years? 5 years? If it changes frequently that's great - someone could be put to task to monitor. If it changes very rarely, you will have a surprise outage although I am guessing debugging and fixing it would not be an issue unless you have SLAs you need to keep up with.

I wonder what kind of monitoring and alert system must exist if any cloud provider changes their SDK or APIs (signature, logic, capability etc.) upstream while your go binaries are in production. Did Google manage to get cloud providers on board to register and update a 1 to 1 match between the upstream api and the go cloud api?

Secondly on the article's mention on multi cloud usage, you would need to be a pretty large place to need (or even bothering to assess and convince yourself that you need) to use multiple cloud providers at once. Just learning and tweaking settings in the cloud providers GUI console is half the battle won sometimes.

Saying all this, this, together with the data portability announcement, it is definitely great for competition and going to bring great resilience in your code base to be SDK agnostic.

I was talking about it in a proverbial manner - that the search for a co-founder would have to be methodical and systematic akin to sales. It can be excel, airtable, hubspot etc.

In gitlab ci, we run govars.sh which not just sets the gopath but also adds the "bin" folder to PATH. Then when we run tests we know where to get our compiled binary from. Our govars also sets the path on where to find our conf.yaml for env config. Didn't know it would cause so many issues in Jenkins!

Can someone help me understand why people hate gopath? We have a script called govars.sh at the root of every project and it sets the gopath exactly the same way one would use virtualenv in Python. We remove the default one from .bashrc or .profile. This basically makes gopath disappear entirely - we never bother explaining to new devs what it "really" means. Just ask them to use our template project folder structure.

I am a non-technical co-founder who after a year of building product, has acidentally become a full time software engineer (as our product was horrendously complicated - not always a good thing). Now I am going back to doing biz dev and market development.

At the begining, I literally crawled, begged and did anything and everything under the sun to convince technical people to join me. The waterfall looked like this:

- Say I contacted through events/linkedin/accelerators/friend-of-friends/facebook/CS-professors about 100 people (number was definitely larger than this)

- Something like 50 even bothered replying

- Something like 20 bothered having lunch with me

- Something like 10 sat down for a second meeting to look at whatever code I already had

- 5 I had maybe a week of work done together closely, discussed the challenges and arrangements closely etc.

- It didn't work out with 4 of them for various reasons - simply didn't click in some way

- 1 eventually quit their job and saved my ass. We are all full time now though of course.

When I was presenting to technical people, I had a friend doing a PhD in CS who cant quit his PhD but wrote some serious c++ code (as our work dealt with large matrices) while I wrote a web python backend to serve the cpp code. And I had a deep background in industrial engineering and finance. So I think the 50 evaluated our work and bothered replying took a reasonable guess that my chops were "not bad".

Then 6 months later it was intern season and I did the same thing again. Then I did the same thing to get funding. Then to get customers. Getting full time staff that is proverbially "ninjas" is even harder than getting investors or customers. One is committing their lives to you and another is just a procedural budget decision. Then it follows that it should be even harder for someone to co-found something with you.

After a while I started using a CRM and a systematic funneling for everything that has a 80%+ fall off rate. Which is literally everything in a startup, from newsletter opens to fundraising to good interns.

You should do all the things adviced in this thread, then assume that if there is an 80% to 90% fall off, how many of them you should do (more accurately: NEED TO DO) on a per week basis to hit your final target. Because of the last 10% who didn't fall off, you still have to reject the 9% who you can't work with, don't like the business idea personally, don't think it is a viable idea etc. If you use an accelerator's services to shortcut the process above, remember you have to pay them 6% to 8% of your eventual company and its 50-50 whether they can perform the search service well - so its cost is approximately 3% to 4% of equity.

Good luck!

Would like to add "habit of drinking water" to this list. ANY beverage whether its coffee, soda, tea - is easily 4 to 6 dollars and is an entirely made up requirement.

Yes decommissioning is an integral part of the project and regulators and lenders mandate you to set aside funds for it before the first brick is even laid. Knocking them down is part of the project's economic and environmental risks evaluation. Projects can be rejected by regulators if there is no feasible way to run it or knock it down without irreversible damage to the natural environment or communities.

Nice, I am a hydropower guy and its rare to see river / hydro related things on front page!

Apologies in advance for the oversimplification. It depends on the actual contract you signed but in general it goes like this:

VC puts in 1 dollar, you sell at 1.2, VC will take the first dollar and MAY take the next 20 cents. That could mean a liquidity preference of 1.2x. If you sold at 1.4, it COULD mean VC takes 1.2 and you split the next 20cents according to your share split with the VC.

It may be easier to think of a VC as a bank that doesn't ask you to pay back a loan every month BUT if a liquidity event occurs (i.e. someone buys your company), they absolutely want all their money back first (i.e. "senior" in debt to equity holders (you)) before you get to dip your hands in.