stackzero

The next step is to open source your family as a project on Github

In a similar vein, I ran a little experimental project using redis as a distributed filesystem using this: https://steve.fi/Software/redisfs/

I don't fully understand all the networking protocols involved but who/what is responsible to manage this kind of failure in the network? How should this ideally be handled besides cloudflare engineers calling someone?

The problem is there's no clear way to get started with setting up a python package. Every other day someone ask a question on SO about it and the first google result is outdated distutils IIRC

Why the name playdate?

I like the idea but it seems the author is just slicing the normal distribution at a point of interest and calling it bifurcated? e.g. with the phone example. "good enough android" or "iphone / flagship android" all the actual phone models are hidden under two higher level labels. Isn't every decision making process with buying essentially try to get the best for your money?

As someone else who is not versed in CSS this is epic

One of the big challenges with data ownership is policing it. If I grant one-time access to my data to some company, the company can store the data and use it many times over, potentially distribute it etc.

I can see this working for datasets like website interactions or search history which companies could pay a subscription for and receive periodic updates which would be of continued value.

"consequences should be protective, not punitive." - Couldn't have put this any better

Some practical things that have helped me, by no means an expert:

1. Practice writing new project's from scratch. not so much todo apps but challenge yourself e.g. I wrote my own function as a service engine

The main point of the exercise is to show: - Best practice is contextual, so first you need context ;) - Think about the big picture and all the pieces to get there - Repetition. It will help you improve your development flow and process, and become better at your craft

You can borrow design/implementation ideas from current projects that you're familiar with or use a design pattern you found on a blog etc. it will help you recognize when certain practices are the "best".

2. Rewrite this code continually. Is there a better way? more concise? faster? easier to test? It seems there's many ways to do the same thing. Which one is best depends on the situation.

3. Optimize last. No seriously. If I could count, the amount of times I've thrown away code because I optimized to early...

tl;dr best practice needs context. This requires big picture thinking. Learn to recognize contexts and the best practices are alot clearer

Nice work. Stuck on mac at the moment but am excited to try this when I can

How does this address the last revealer problem?

Have been using and recommending this for the last few months. Found it easier to customize vs. amethyst

Harvey Dent put it best- "You Either Die A Hero, Or You Live Long Enough To See Yourself Become The Villain"

Harvey Dent said it best "You Either Die A Hero, Or You Live Long Enough To See Yourself Become The Villain"

TBH get comfortable with writing a web server in your favorite language and a popular framework e.g. flask (python), go (gorilla/mux), nodejs (express). Then try using it to make calls to an external system like a database. As a backend developer you should have a good feel for the data flow through the application stack.

There's nothing special about backend development, its mostly about the "plumbing" between systems. Lots of de(serializing) (e.g. json, protobuf) messages into objects and validation of those messages

I think the high wages are due to a lack of understanding from non-programmers. Non-technical folk see it as scary or hard to understand so would rather pay someone else to handle that stuff. We're on the inside looking out, not everyone wants to understand. As I'm sure we're all familiar with- i.e. the conversation killer of explaining our day job or even mentioning I'm in software/IT/programming etc.

What's new?

When's your ICO?

Currently, designing and building blockchains.

> Digital currency can only be the #1 use case if we find a generic, uniform way to pull in real-time real-world data of which we can verify its confidentiality, integrity and availability.

I'm not sure I understand your point here

> Do you think fintech/banks can work use public ledgers?

The only reason they'd want a public ledger is for transparency with end users. This isn't high on their priority list but more importantly there's too much at stake to leave the protocol up to anonymous public participants.

Consortium chains make a lot of sense in these private B2B transfers. Which is the goal of something like Stellar as the only incentive to run a node is to keep the ledger/service lively. It is also a better engineering tradeoff to have a dedicated chain to process Txs only you care about and not have it degrade from cryptokitties. Lots of blockchain projects are moving to this parachain model. E.g. substrate, tendermint, plasma protocol

> It appears some states are already legally recognizing smart contracts

That's good to see.

FWIW I don't like the idea of a future where we need special solidity lawyers to verify some code matches its legal obligations. Which is why the Ricardian format is so appealing. It should be accesible to all

Btw thanks, that harvard link is a good read!

The point I'm making is we can agree some paper is truth or that a distributed ledger is truth. Failing to send a transaction should void the sale in the first place e.g. Hashed time locked contracts. With some proof of authority logic we can facillitate updates to the ledger by courts or governing bodies i.e the same as adding some new paperwork currently

I really appreciate having a high-level diagram of system architecture when joining a new project. It gives me an instant feel for whats going on and even if its slightly out of date it gives context to the evolution and design decisions of the codebase since then. That said, there's nothing that beats the good ol' step debugger and diving into the code first hand. They're complementary. Without the diagram its kind of like building a mental model of a room by feeling it out in the dark.

Edit: I'm not too strict on UML exactness, as long as it gives a feel for the components, data flow, etc.

All the people who develop OSS in their free time. Text editors, plugins, kernels, package managers, compilers, the list goes on in any ecosystem. The number of these projects I interact with knowingly and unknowingly on a daily basis is ridiculous and represents the cumulative effort of many. My day job is all the better for it, so I take my hat off to those awesome folk.

Thanks for all the hard fought PRs, features, and optimizations that make our lives as developers what they are today.

Most of the time because companies are hiring out of necessity. They either need to deliver more, faster, or are lacking technical leadership / expertise. This means the team is under enough pressure to deliver as is and don't have resources or incentive to onboard a junior.

My advice is to keep learning on your own time, push yourself to learn a valuable skillset e.g. React (as you say you do frontend) and make something with it. For a new hire getting familiar with a project is a given, even a senior needs time to do this. However knowing a language, framework, or skill is your responsibility before applying for a job.

I've applied for jobs that were above my experience level but ended up getting hired anyway while I didn't have enough "years" under my belt I knew the domain and tech stack required for the job. This often meant when applying for a senior job I'd get signed as an intermediate and same with intermediate roles where I was hired as a junior. Once your foot is in the door, if you work hard it will be apparent that you're adding the value of more experienced member than your current job title and from there its an easy promotion discussion.

Just my 2cents. Know your stuff, that's your job and stay humble the promotions and opportunities will come.

> In my opinion everyone company likes to only benefit from experiences earned elsewhere but never like to provide folks a place to earn the same in their company

^ this, can't agree enough.

There are certainly many moving parts- but there's nothing quite like running kubectl create -f <somefile> and sitting back to watch your entire application stack spin up

The canonical example of serverless is for handling web requests i.e. 1 function per HTTP route. Database will still need to be on a static server. Managing user login / state etc. will be cumbersome across multiple different functions, however the email and payment processing handlers may be better candidates for serverless functions. A thin front-end and DB on static servers with serverless used for emails+payment processing would be a good initial architecture

It can be abit of a pain if you're not using linux OS as the server. Setting up secure image registries or registries in general is also tricky. It can be tricky learning how to debug dockerised applications because of the extra layer of indirection.