https://assets.atlasobscura.com/article_images/54191/image.j...
Does anyone happen to know the meaning of "пояс" (belt) in the pricing scheme on the same box?
3,253 karma · joined March 15, 2008
https://assets.atlasobscura.com/article_images/54191/image.j...
Does anyone happen to know the meaning of "пояс" (belt) in the pricing scheme on the same box?
Regardless of all of that, in my experience a typical impressive hackathon project is still just a barely working demo that benefitted from a significant amount of research and planning beforehand, and will require an even greater amount of hardening and polish afterwards.
There is no magic, it's just a vastly different kind of work environment with both inputs and outputs incomparable to day-to-day work.
That said, what's this about exit visas? Is it being seriously discussed?
It's just that such challenging environments trigger the problems first.
There is a significant cost to compliance, even if you do it right from the very beginning (assuming it's even possible for GDPR right now), and for a lot of startups it's not worth it to spend time on that because they'll most likely be dead for unrelated reasons before they get any significant amount of GDPR clients.
It makes more sense to spend the effort on not dying instead of chasing incremental gains in markets with complicated regulatory requirements, unless dealing with those is explicitly your business proposition.
For example, things like the company actively seeking out clients in EU countries, or offering the service in EU countries' languages, make it more likely that EU will consider the company to be subject to GDPR even if it has no presence in the EU.
It seems to me that EU is overstepping their jurisdiction here, but I really don't know how international law works.
---
I don't really see a problem with targeting the biggest worst abuser. Not everything has to be a one-shot solution to grand problems.
And honestly I don't think any significant amount of people search Google images wanting Pinterest results. People want images, they don't care where they're from. AFAIK there is almost no OC on Pinterest anyway.
Tables are just unstyled boxes with an alignment rule. Not very high level.
Buttons are provided by the host OS, HTML and CSS have nothing to do with their default style or behaviour, and if you start styling them you basically revert to working from unstyled boxes.
On the web the role of desktop UI frameworks is distributed between third party frameworks such as Bootstrap which is great because those are optional.
I haven't worked with the windows frameworks you mention to compare directly to them.
If you want, you can make a framework on top of it that will behave like a desktop UI framework with standardized elements and behaviours. There are plenty of such frameworks actually. But not having to use such a framework is nice.
Besides, the current browser environment has been historically heavily optimized for websites, not desktop apps. If it became a popular choice for desktop app UI we'd have developed more appropriate features for that use case.
- Create a new, anonymous email account and use that for accounts that you care about to minimize the chance of successful social engineering attacks
- Depending on how serious this is and how much the hacker knows, consider warning your friends and maybe even colleagues about the situation
- Obviously don't have anything visible to friends-of-friends or to the public on facebook, remove your public photos especially those that can be photoshopped into a fake id, etc.
I'm not an expert in this, just some ideas.
"this will be re-evaluated every time you access it"
But more importantly, the whole premise is wrong. "Cache invalidation" for data that has an average lifespan of 30 lines of code in a single function is not a hard problem. Real cache invalidation is hard for reasons that don't translate to the case of ephemeral constants with properly limited scope.
You get a result from a call to `foo(bar)`. You have to _do something_ with that result. One common thing you'd need to do is to call another function: _baz(foo(bar))_. But then you're just hiding the assignment inside a baz function call (the result of _foo(bar)_ will be available as a variable/constant inside of _baz_).
That doesn't so bad if you only need to do one thing with with the result of `foo(bar)`. Now what if you have to do something with that result twice. In this case all you've done is reduce the scope of a constant to be smaller than it needs to be, requiring you to make a duplicate `foo(bar)` call.
Now you're repeating yourself and you don't know anymore if you're conceptually dealing with the same result or if foo(bar) might produce a different result on second call. You removed philosophical/semantic meaning from your code and did not gain anything from it.
If you find yourself wanting/needing to "expire" variables that you define before you run out of scope, then the answer is a combination of:
1) use constants of immutable data structures, not variables or mutable structures 2) better name such constants so that you know what they represent 3) better manage scope and function size
In practice, the above is much easier to achieve than what you're proposing, and makes the code easier to read and maintain.
> The right way instead is to evaluate (or "re-evaluate") the function every time you need it unless you have a good reason not to (the only good reason is that the function is a bottleneck that affects the experience of the user)
That does not scale to using the coding paradigm that you're proposing application-wide. Your whole app will be one big bottleneck because it's doing a multiple of the computations that it needs to be doing, with no easy way out. I guess you can get away with that by throwing more money at your backend infra, but you can't do that on mobile or for web frontends or desktop apps.