It sounds different to me - a regular git submodule would keep all history, unlike a file storage with occasional snapshotting.
1,116 karma · joined May 31, 2014
Example (had to search on kagi with site:minifeed.net):
You Can Either Steal Great Developers or Farm Them To grow software development teams, you can either steal excellent developers or you can develop them internally.
It's a cool idea, but maybe a improvement could be to select a random handful per day, and let them stay there for a while? Fewer surprises this way!
I'd advise to put it at the top, before the text, to let people know beforehand and not be caught off guard. Then you can have a big button saying "read full article in website" or something, to make it easy for people to see both options.
A: You're handling problem X and then unrelated problem Y suddenly arises because you're not locking package versions thoroughly. It's not fun.
B: Now the opposite. You lock all versions of the libs you use. You use renovate or schedule time for updates periodically. You have a thorough test suite that you can automatically exercise when trying the new updates. You can apply the updates and deoy the new version to a test environment to run a final test manually. Things look good. You deploy to production and, quite often, things go smoothly.
A is the blue pill, easy to taste but things are out of your control and will bite you eventually. B is the red pill: you're in control, for the better or worst.
Let's not be naive, or deceptive, about a malpractice from a multi billion company owned by a multi billionaire.
To me, the bad part is the tax reductions only appear in behavior I don't agree with: high overtime and tipping (when it's semi mandatory).
I'm not American, but this is also showing up in my country.
They are testing an hypothesis, we don't know if they're optimistic or pessimistic about it. Is it even relevant?
They have studied that LLMs can be easily confused with non-sequitors, and this is interesting. Maybe prompts to LLM should be more direct and foccused. Maybe this indicates a problem with end users interacting with LLMs directly - many people have difficulty on writing in a clear and direct way! Probably even more people when speaking!
- Steve the bartender - How to drink - Cocktail time with Kevin Koz - The educated barfly - Anders Erickson
Good recipes, sometimes adding new things, but usually tasteful.
But maybe they're better to search for than to strictly follow regularly; there's so many cocktails that is impossible to buy all ingredients or try all of them.
It's really satisfying to optimize (or any kind of refactor) on well tested code. Change the code, run the test, fix if it fails, keep it if it passes. Sometimes the code was not well tested, but it was slow, so there was double the reason to test and improve.
Having deterministic data for comparison is also good in a different perspective: slower feedback loop, but usually more variety, with edge cases you didn't think of. Transforming thousands of data points and getting 0 diffs compared to the original results is quite the sanity check!
Measuring can be difficult but really rewarding. I was doing this very technical work, but constantly writing reports on the outcomes (tables and later plots) and got great feedback from managers/clients, not only about the good results (when they happened, not always!) but also about the transparency and critical analysis.
We didn't really work with acceptance levels though. It was usually "this is slow now, and we expect more data later, so it must be faster". But it makes sense to define concrete acceptance criteria, it's just not always obvious. We'd go more in terms of priorities: explore the slow parts, come up with hypothesis, chase the most promising ones, depending on risk/reward. Easy fixes for quick wins, long stretches for potential big gains - but try to prototype first to validate before going on long efforts that may be fruitless.
Usecases:
Log: search, get context, read
Metric: measure, plot dashboards, define alerts
My theory for the concepts being so mixed up together: you use both to troubleshoot, and I think the old school way to emit metrics was to parse logs and turn that into measures.
I'd describe a really simple setup as this:
Pod: you put 1 container inside 1 pod - you can basically replace the word "container" with "pod". Let's say you have 1 backend in python and 1 frontend in React: you deploy 1 pod for your backend, and 1 pod for your frontend. The simplest way to deploy pods is not with "Pod" but with "Deployment" (1).
Service: Kubernetes really doesn't want you to connect directly to pods, it wants you to have a service in between. This is sensible because pods are ephemeral - they can be killed due to crashes, updates, etc. You define a service, point towards the pod, and all internal requests should be sent to the service, not to the pod. (2)
(1) https://kubernetes.io/docs/concepts/workloads/controllers/de...
(2) https://kubernetes.io/docs/concepts/services-networking/serv...
Note: technically, a pod is a group of containers. It can get more complex than this, but it's not unusual to have a group of 1 pod, especially in simpler setups.
So, some kudos to Robert for accepting criticism and discussing it, but no cigar for downplaying his own advice when confronted - I also recall a different discussion, where someone confronts his statement "you don't practice tdd you're not a professional", and his answer "it was not meant to be taken seriously".
These people had great ideas but they should be more critical of themselves, eg "here's when not to apply this", "here's where to bend this", not "you're doing it wrong" or "don't take it literally".
If you're training models with billions of parameters, you're still gonna need that.
> when work is done, I leave, and it's done.
My experience from WFO is worse: task may be done earlier, but feels wrong to leave earlier, and colleagues may not take it badly.
>not using my resources (electricity / broadband / etc) for work
Gas is more expensive than electricity, so I'll take the tradeoff. Even better if you can reduce the number of cars in the family - purchase, annual fees and insurance, etc.
> easier interaction with colleagues
A pro and a con: good for collaboration, but also easier to be distracted when trying to focus.
Many launchers came to be, with half assed community features. They didn't want a thriving marketplace, they wanted a piece of the pie. People hated them and they died.
Recently epic store came, with a billion dollar Corp behind, and they are fighting the long battle. The free games are a nice thing (usually older offers or curated indie stuff), but the exclusive business sucks. Luckily it seems unpopular, and fewer brands esnt to adopt it - some are so strong they can do it, but others found out that they can lose their loyal costumers and fade out, eg Borderlands.
They got a few customers from their giveaways - they should stick to those and further improving their store, maybe some people will actually want to use it.
A man and a statiscian are walking down the street when they see a 50€ bill. The statistician keeps walking but the man stops and says "hey, look at this cash on the floor?". But the statistician, uninpressed, says: "must be fake, or someone would have already picked it up". And continues walking. The other man grabs the cash and takes it.
/s
It's true that anime (as in: TV shows and movies) is more popular than ever, but its business has lots of problems. I'd love for someone to improve this situation, so that we could have more episodes of beloved sagas that are somehow paused, eg Berserk and One Punch Man.
But I'm completely uninterested in AI generation or parasocial stuff. Let art be art, even across mediums (comics, TV, games), but the rest just sucks the humanity out of the art.
With The Hobit , there was a change in directors (originally Guillermo del Toro) and lots of studio meddling (eg pushing for 3 movies when the original is a 200 pages book, inclusion of LOTR actors for wider appeal).
I think Peter Jackson was brought in to try to salvage what he could.
Maybe a better analogy is a bank with open lockers and no vigilance: if someone enters and steals money, the police will look for them, because "the coffers were open" is not a valid defense. But customers will also demand answers from the bank - why were they so negligent and incompetent that someone can just enter and get their money?
We should hold similar values for digital systems.
Was the author's intent on stealing private data and causing harm? Did he gain from this abuse? Did the company take enough measures to safeguard their data?
Companies have been mostly not held responsible for their fuck ups, and no matter the law, that's wrong to me.
Secondly: can consumers be blamed for gross negligence? It's not reasonable for a bank to post account balances in public billboard and ask people not to look at others. We should contest when private data is available publically, hidden only by small obfuscations, not professional security practices.
Cannot auto complete at start:
My auto complete doesn't work at the start of a list expression. In [for obj.abcdef...], what is obj? It cannot know. In a callback, using typescript , it knows: list.forEach((obj) => obj.acdef...): obj is an element of list, which, if typed, we can infer its value.
It's minor but it's not optimal.
confusing multi line comprehensions
I don't know how to format this in HN, but this is pretty weird in multi lines: [obj.y \n for obj in my_list \n if obj.x >3 ]. Something like this reads much better: my List.\nforEach((obj).\nfilter((obj) =>obj.x >3).\nmap((obj) => obj.y))
I'm comparing with Javascript which I don't enjoy much either. But I liked using this style in C#, with the LINQ nodule.