I think it depends on the scale of apps you build for. One can deploy a simple backend API or web app to a PaaS like Heroku or Zeit, or even a PaaS-like environment managed by another team, without knowing much about distributed. I would consider someone that can do that + build a modern front end as full stack.
IMO the average CRUD web app doesn't have the scale to have distributed systems problems. Also there are managed service versions of everything these days even when one scales up.
Yeah. And the scales have to get pretty crazy before "rails on postgres with some in-memory caching" stops cutting it. Your average developer will never see it.
I believe a basic understanding is enough to be a Full Stack engineer. For example, it would be enough to understand that my horizontally scaling backend would imply stateless servers. It may not be necessary to understand how the clocks are synced across my clusters.
They have debt because they don't want to move money from foreign accounts to the US so they borrow money to pay dividends, but they don't have net debt.
Honestly the format looks a bit over-engineered IMHO. The task is quite simple: make build system that executes jobs on clusters. So why not get best build configuration format practices and just make them run over network? For example ninja build system [1] format is quite good in my opinion, so just make runtime execute commands over network. Or travis-ci [2] is another example of well designed configuration format, and it really enables developers to write small and powerful configurations. Sure it was even done before (though mostly for C/C++ stuff), like IncrediBuild [3] for example, or FASTBuild [4] or distcc [5]. Though the case with precise control of pipes could be improved in current build systems, but not sure how important it is for this application.
I think it's especially true for make - looks like it was designed to efficiently express operations for transformations of the same type (like .cpp -> .o/.obj). So in different use case it may become a bit clumsy to use. Ninja should help a bit in this case - you can define a rule, and just use rule name when defining inputs and outputs of a build statement, though it still operates on files.
>[Problems with] combinatorial dependencies
Yes, partially this could be fixed with wildcards in make. Ninja doesn't have wildcard support, so I've created the buildfox [1] to fix it :)
>Non-representable dependency structures
I think it's a limitation of this type of build systems, their configuration language oriented on expressing "how" to achieve things, not "what" to achieve.
Lets be practical, I am sure the actual app
- Works without network connection
- Metrics (offline syncronization)
- User logins
- Includes price of iPads themselves?
- Involved government and IBM personal
Feel there is really no way to prevent this. This was doubtfully uploaded knowingly (or possibly with ignorance). Data dumps occur all the time. As a file, they can too easily be shared. For sure, the school should work on increasing their awareness of handling secure data. But, in the end, nothing would really prevent this from happing again.
I'm imagining IT has proviosned certificates on the computers under their control that allows them to do a MITM attack on either blacklisted sites, or non-white listed sites.
