The question is: what tool to use? I'm a solo developer running a very small kube cluster for my hobby project. I very much wanted to have a declarative version controlled state of my cluster. Every time I try googling solutions I get flooded with some enterprise Saas offerings that do nothing I want.

I managed my stateful sets/services for a while with terraform, but my experience was absolutely terrible and I have stopped that eventually. I now use "kubectl patch" and "kubectl apply" with handwritten yaml, but the workflow feels very clunky.

Intuitively it seems obvious to me that there must be a tool helping with that, but for some reason I was absolutely not able to find anything that would be even a little bit helpful. I am considering writing a couple python scripts that will automate it.

kubectl apply on a directory full of yaml works fairly well for small stuff. Check it into git and it's version controlled.

If you need something more flexible than that, try making your own helm chart. Helm will give you some text templating, pre and post hooks, some basic functions, and some versioning and rollback functionality.

You can start simple by just pasting in your existing k8s yaml, and then just pull out the pieces you need into variables in your values file. If you need to change an image version, then you just update the variable and `helm upgrade mychart ./mychart`

kubectl apply on a directory doesn’t work because deleting a resource manifest won’t delete the corresponding resources.

It does work, as long as you’re not deleting anything. :) That might be good enough for a “very small kube cluster for my hobby project”

I only use ‘kubectl apply’ for small stuff where I only have a couple resources. Anything more complicated and a tool like helm is much more useful.

'kubectl delete -f dir/' will delete all resources in the directory.

Right, but the only resource you want to delete is no longer in that directory, so you’ve now deleted every resource you except the one you actually wanted to delete. :)

Ah, I slightly misunderstood. Still, you should always have your manifests under version control so this shouldn't ever be a problem :)

I'm a fan of emrichen, but simple text templating (Jinja) works almost as well. (j2cli means you can just provide a yaml file with per-stage configs.)

Fluxcd, or argo CD if you want a nice UI

My reasoning here is as follows:

Putin doesn't care about money - he has all the money he needs. He doesn't also care about welfare of average Russian citizens as long as he can stay within power.

He cares mostly about staying in power and by extension about others perceiving him as a good leader. It is incredibly obvious to me that dictators don't end well when they lose their power. I assume losing power is as bad outcome for Putin, game-theoretically as getting Russia nuked to the ground.

Over the last 30 years Russia was progressively losing ground within its' sphere of influence. Poland, Ukraine even Belarus are slowly fading further and further away. All the context for today we need is the Orange Revolution, Euromaidan and recent protests in Belarus which show high level of anti-russian and pro-western sentiment among society of these countries.

When those countries turn fully pro-western, with relatively wealthier and happier citizenry, it's a matter of days rather than years when the same sentiments will reach Russia, leading to a quick change in Russia's top-level government.

If Putin wants to stay in power, he must convince people in Ukraine and Belarus that it's in their best interest to stay on his side. And lethal force is really the only tool he has at his disposal for it.

So his options really are: - Hope that he can cling to some remaining bits of power until a reasonably peaceful end of life and be aware that probably soon afterwards Russia will start turning pro-democratic. - Do whatever is within his control to keep Ukraine and Belarus subdued.

Weighing pros and cons in this particularly hard situation, he must have chosen that option number two has a higher EV to keep him in power for longer. What can happen now:

- (best scenario for the democratic world) Ukrainian forces manage to defend themselves from the offensive. That basically means Russia's collapse as it is today. It's probably in the best interest of many western democracies to maximize the probability of this outcome, but I'm not sure how probable it is really.

- (worst scenario for the democratic world) Ukraine is taken over completely very quickly with minimal Russian cost and loss. World doesn't really have a chance to react. Russia weathers sanctions ok and gets into closer ties with China.

- Russia cripples Ukraine military, the war drags on guerilla-style. Russia manages to successfully occupy part of the country and the rest becomes warzone wasteland. Russia saves face, Ukraine and Belarus and under complete control.

- War drags on and Russian can't continue with the cost of it. Ukraine gets severely weakened but manages some resemblance of independence while Russia occupies only very minor territories. May be enough for Russia to save face, but I would bet not really and it would lead to another scenario where Russian government collapses.

- Western allies get involved in the conflict, but none of the sides decide to use nukes. Russian military will get destroyed and Russian government collapses.

- (worst scenario for the whole world) Western allies get involved in the conflict, and one of the sides decide to use nukes. Humanity's development gets moved back hundreds of years.

- China and Russia are in active cooperation. Russia will keep escalating the war in Europe until one or all western nations engages. On that day China begins offensive on Taiwan and attacks US. WW3 starts.

I believe in most of the countries in the world military command is playing out all of those and many more potential scenarios. I would like to live in more boring times.

Seems like an awesome idea, but the first thing I see when looking at it is that's one big chicken and egg problem - it'll be an awesome platform if it gathers a critical mass of bands and users, but before then probably will feel like a dead place for a long time. What's your plan for overcoming that?

Thanks! And yes, that is one of the major hurdles right now. Currently, we're working on tapping into our personal, music industry networks to start the first round of performer signups.

Right now, we're basically in a "gathering feedback to see if this is worth pursing" stage. So if we decide there is enough interest, and once we build out the campaign element, and can prove that this model works with some successful campaigns hopefully it will get some legs over time.

I would prefer we had a stone cold plan for growth but right now we're taking it day by day and seeing what feedback we can get as we move forward. I would appreciate any ideas you might have!

> This is like if the world's best chess AI had gone from losing high school tournaments to being competitive with Kasparov in less than 3 years.

I don't think it's like that at all. On the high level, there is no "chess AI", "go AI", "image classification AI" and "dexterous manipulation AI". These are all sides of the same coin, that gets significantly better every year. Adding support for the new game or new "environment" to existing deep learning based backbone still requires a bit of engineering work and a few creative tricks to unlock the best possible performance, but the underlying fundamentals are already there and are getting better and better understood.

There is a reason why the progress in AI is so hard to measure. Anytime a next task is solved, there is a crowd saying it's not a "real AI" and that scientists are solving "toy problems". Both statements are totally true. But the underlying substance is that each of these toy problems is of increasing complexity and brings us closer and closer to solving the "real problems", which are mostly so undeniably complex that we couldn't attack them upfront. Still, the speed of progress in the field of AI research is staggering and it's hard to keep up with it even for professional researchers who spend all their waking hours working on these things.

6 years ago we were able to solve some Atari games from pixels. Today, that feels like a trivial exercise compared to modern techniques. With billions of dollars of investment pouring in and steady supply of fresh talent, it is very hard to predict what the pace of research will be in the coming years. It is entirely possible we'll encounter a wall we won't be able to overcome for a very long time. It is also possible that we won't, and in that case we're in for a very interesting next few decades.

> On the high level, there is no "chess AI", "go AI", "image classification AI" and "dexterous manipulation AI". These are all sides of the same coin, that gets significantly better every year.

On a practical level, this is not true. There are different algorithms, different architectures, different hyperparameters required for each of these problems, and often for each subdomain within each of these problems, and often for each specific instance of these problems. It's difficult to draw any kind of holistic picture that combines all of the individual advances in each of these problem instances; that's why progress in AI is so hard to measure, and why a statement like "each of these toy problems...brings us closer and closer to solving the 'real problems'" is probably a bit too coarse-grained to be fair as well.

I don't mean to imply AlphaZero is not impressive; it surely is. Nor do I mean to imply that any of these advances aren't impressive. I do mean to imply that "closed-world games with well-defined rules" is a relatively small subdomain of problems. And that BERT looks pretty different from AlphaZero.

First of all, nice comment! That said,

> Anytime a next task is solved, there is a crowd saying it's not a "real AI" and that scientists are solving "toy problems". Both statements are totally true. But the underlying substance is that each of these toy problems is of increasing complexity and brings us closer and closer to solving the "real problems"

I wonder if this is true. This belief may seem like common sense, but it's not obvious to me that domain-specific problems must generalize to General AI ("real problems") or even bring us closer to it. That is, it's not evidently true that many small problems will eventually lead to a general solver of everything (or to human-like intelligence). Or to say it in yet another way, it's not obvious to me that human-like intelligence is the sum of many small-problem-intelligences.

Again, common sense may lead us to believe this, and maybe it's true! But I think this conclusion is far from scientifically evident.

The key thing you're missing is transfer learning. Instead of starting from scratch, you start with a model that was trained to do something and then train it to do something else. It takes much less time and labeled data to get the model to do something similar.

You can even interleave the training for the second task with a few training rounds for the first task to maintain proficiency. There's a group that's using this sorry if technique to make a general "plays videogames" AI. I couldn't find a good link from my phone, but here's a less good link about something similar: https://towardsdatascience.com/everything-you-need-to-know-a...

>> On the high level, there is no "chess AI", "go AI", "image classification AI" and "dexterous manipulation AI".

As another poster said these are all tasks performed by different systems. For chess and Go AI it's Deep Reinforcement Learning with Monte Carlo Tree Search. For image recognition it's Convolutional Neural Networks. Importantly, these systems are very task-specific. You won't find anyone trying to beat humans at games using CNNs, for example, or using Deep-RL to do text recognition. Far from "a few creative tricks" these are systems that are fundamentally different and are not known to generalise outside their very limited domains. They're one-trick ponies.

The OpenAI paper on "dexterous manipulation" reported learning to manipulate one cube, the same cube, always, after spending a considerable amount of resources on the task. It was a disappointing result that really shouldn't be groupwed with CNNs and Deep-RL for game playing. The level of achievement does not compare well.

>> Anytime a next task is solved, there is a crowd saying it's not a "real AI" and that scientists are solving "toy problems".

This used to be the case a decade or more ago. In the last few years the opposite is true. The press is certainly very eager to report every big success of "AI"- by which of course is meant deep learning.

>> 6 years ago we were able to solve some Atari games from pixels. Today, that feels like a trivial exercise compared to modern techniques

6 years ago DeepMind showed superhuman performance in seven Atari games with Deep-RL (DeepQN in particular): Beam Rider, Breakout, Enduro, Pong, Q*bert, Seaquest and Space Invaders. Since then more Atari games have been "beaten" in the same sense, but many still remain. I'm afraid I can't find references to this but I've seen slides from DeepMind people a few times and there is always a curve with a few games at the top and most games at the bottom, below human performance. There are some games that are notorious for being very difficult to solve with Deep-RL, like Montezuma's Revenge which was claimed to be solved by Uber a couple of years ago however this was done using imitation learning, which means watching a human play. The result is nothing like the result in Go, which remains the crowning achievement of Deep-RL (and its best buddy, MCTS).

Bottom line: Atari games remain anything but a trivial exercise.

And the architectuers that play Atari do not perform as well in Go or chess, say. You are mistaken that it's simple to train the same system to do all of those things. The AlphaZero system that played Go, chess and Shoggi well enough to beat its predecessor (you will excuse me that I don't remember which incarnation of Alpha-x it was) had an architeture fine-tuned to a chessboard and pieces with discrete moves, so it would not be possible to reuse it to play Starcraft, say, or even tic-tac-toe. The cost to train AlphaZero is also very high, in the hundreds of thousands of dollars.

I've used both in production and I must say I'm a very big proponent of both. Actor model of concurrent computation I think maps very well to, at least my, way of thinking and I think is the most productive way of writing distributed systems.

Elixir/Erlang/OTP: + Very mature, very well thought out. While the newer stuff may feel a still under construction (string handling, date handling) all the concurrency primitives are rock solid, and by rock I mean diamond. + Elixir is simply a great language and you can get quickly very productive in it once you grasp the actor/process model of BEAM + Has one very big advantage over akka that actors can receive messages in different order than they were sent. That of course can cause some headaches if not handled carefully, but 99% of the time straight up leads to nicer and simpler programs. Really a lot of akka code very often is just written to deal with the order in which the messages may arrive. + Truly resilient with very good error recovery design once you know how to work with it. I still don't know more graceful and productive way of recovering from failures in a running system.

- For doing any expensive computations it's slow and it's a fact. Not much can be done about it. - Library coverage is 7/10 or 8/10, but these few missing points can sometimes make a big difference.

Scala/Akka: +/- I love Scala language and static typing, but one must be honest that it's much more complex. You can learn Elixir (without macros) in an afternoon. One really needs to take some time and think it through to utilize Scala properly and a true mastery lies even further. To be fair proficiency with Elixir macros also requires a considerable effort, but one can go very far with Elixir without writing macros, while with Scala already the upfront cost is pretty high. + Up to my best knowledge Akka Streams is completely unique and completely amazing library that is gaining support throughout library ecosystem. This is one point where Scala/Akka completely outshines everything else. Streams are such a great abstraction and gave a huge productivity boost to most of the projects I was working on. Compared to that, elixir GenStage feels much less robust and polished. + Speed of JVM should be enough for 99% of applications, and with that respect it wins with BEAM. + Java/Scala library ecosystem is very deep and is simply much more comprehensive than Elixir/Erlang one.

- There are places around akka that still feel a bit immature/adhoc, but the library is steadily improving. It just is not as mature as BEAM/OTP. - Over small and mid size projects I think I was more productive with Elixir. Meaning, if I had the same amount of time, I could implement more features in less time using Elixir. But it could be just a personal thing.

Overall I think both are fantastic platforms and I'm happy to have both of them to choose for each project. If I were to chose what to select today:

- Choose Elixir/OTP for a system where we need to do a lot of io but not much computation and we're sure existing libraries cover our needs. Very big plus if we need it to be resilient. - Choose Scala/Akka if we need speed or call any existing JVM libraries. Very big plus if your project could use Akka Streams.

Agreed. The BEAM run-time and the preemptive scheduler implementation is designed to never block and keep chugging a long; highly desirable for the Actor model. The trade-off is you're further from the metal and raw-compute isn't as powerful as a JVM language like Scala. That said an Actor model on the JVM (Akka) can't make the same run-time guarantees using a cooperative scheduler; instead you get all the enterprise libraries and developer hours to tap into. So the trade-off of more complexity in Scala/Akka is probably worth it for big enterprise who are probably already in bed with the JVM.

I think we'll see more Akka features built in Elixir through things like Genstage and Flow, but it's hard to argue with the mountain of exiting developer man-hours in the JVM.

I can share with you one hiring insight I have that goes against your sentiment. I've been hiring for hedge fund research roles for the last three years interviewing ~30 candidates over that period.

What I've learned is that it is a very weak signal to talk to candidate about "their research" unless it's immediately and directly applicable to what we were doing as a company, so that we can talk about it as equal experts, which never really happened in our case. Previous research done by candidate was, like research almost always is in a narrow and specialize niche. Every candidate I was talking to was very good with talking about their research and from my perspective at the time of the interview it was impossible to validate and evaluate their claims. That conversation could convey the character of the candidate but I couldn't evaluate their ability to do new research.

Instead, presenting candidates with the same problem, that in our case took around 3 hours to solve, in our case proved a good way to compare candidates a bit more objectively and test how they approach solving problems they haven't seen before which is more applicable to what they'll be doing on the job.

The downside of that process is that during three hours you can only test so much, but hiring is a really hard thing to do right and we didn't want to take more of candidates time as we did value it highly and found that to be the sweet spot for us.

The upside of asking candidates about their research is it does a good job of verifying what their contribution is in often highly collaborative environments. Too often I've seen candidates who've worked on super exciting stuff, but not actually been the key contributor. This is way more common in junior roles though.

> That conversation could convey the character of the candidate but I couldn't evaluate their ability to do new research.

It all depends on the questions asked to the candidate. You don't ask them about their research which is publicly available in any case. You ask them questions that let them reveal their thought process about their research. Now, it's up to the interviewer to come up with good questions to make this happen. The interviewer has to be well prepared and think about questions. You don't need to be an expert to ask good questions.

I'd like to reiterate that this applies to research/scientific position where pushing the boundaries is a crucial aspect of the job. In case you are looking for a very specific skillset, things may be different.

I've written a blog post about exactly that some time ago, I hope it's at least a bit enjoyable read: https://blog.millionintegrals.com/kelly-criterion-and-invest...

I've made some effort to provide a set of similar high-quality implementations available in PyTorch: https://blog.millionintegrals.com/vel-pytorch-meets-baseline...

In my opinion PyTorch code is easier to understand and debug for newcomers. Code is definitely lacking in documentation, but whenever there was a tradeoff between clarity and modularity in the end I've chosen modularity. Ideally I would like others to be able to take bits and pieces and incorporate into their projects to speed up time to delivery of their ideas.

+1 on that, that's a great project.

PyTorch with its explicit state that can be easily examined by hand in PyCharm debugger will be way easier for people coming into the field.

I’d be very interested to hear for which similar problems (games, control problems) reinforcement learning is not the best approach (there exists other, qualitatively better method£. We hear a lot about success stories but not a lot about limitations of RL

There are a couple of places where RL/Evolutionary Methods/Something Else are jockeying for the top of the leaderboards, but usually if one technique succeeds over the others it just means that someone's put a lot of work into that one particular approach.

Anecdotally, I've heard about some optimization problems that should be a good fit for dynamic programming or reinforcement learning where it turns out they actually don't seem to work as desired.

For example, optimizing elevator policy: an agent controlling an elevator wants to achieve high throughput of passengers while also minimizing the wait-time of each individual. We want people to get to their floor quickly but also want to avoid having any individual wait for an excessively long period of time. The agent can only observe information about the buttons pressed on each floor, although it gets a reward like that reflects our desiderata[1]. As it turns out, most elevators are not running some sort of cool machine optimized policy, but rather something hand-coded.

This is not for lack of opportunity, either-- apparently, some researchers pitched Otis on this in the 90s, and it didn't work as well as what they already had, despite this looking like a case where theory should match reality. Why this is, I don't know, but it might come down to the fact that there's really a lot more to a "pleasant elevator experience" than might be assumed (or modeled by the reward function), or perhaps the hand coded policy incorporates background knowledge about human vertical locomotion unavailable to a machine.

-----

1. Maybe something `R_{t} = Transporting(t) - ∑ Waiting(i, t)`, meaning something like "number of people currently being transported minus the people who are waiting times how long they've been waiting for".

Or perhaps those researchers in the 90s just whiffed?

It's ostensibly the case for other RL problems that we've only recently crossed some compute power viability threshold. Maybe contemporary researchers with contemporary compute power would have better luck?

One class of examples would be problems where probing the environment is expensive. In many robotics applications, this can be tricky because the robot might break or not return to a suitable initial condition without human oversight. Moreover, the physical experiment can relatively slow so little data is generated, and what is generated may not generalize well. That being said, how to overcome these challenges is a very active research topic in the community.

It probably depends on how you define "best approach".

For example in chess - sure, alphazero is better than stockfish - but stockfish is "good enough" (100s of elo better than the best human), without the cpu-cycle cost of alphazero.

I would like to get a bit of HN feedback on the matter. I am exactly the person mentioned here - an engineer who knows nothing about the management, but because company is growing and we're hiring new people I'm slowly transitioning towards a management position. Just like you've stated I know nothing about the management and all I have is a common sense to guide me which I'm afraid is not enough on multiple occasions.

I'm especially afraid of too much micromanagement, but I don't really know how to handle the process better. Here is my style of management, briefly summarized:

I have a very deep and detailed knowledge of all of our codebase, which is in it's entirety shared by noone else at the company. I've written half of it myself and the other half has been written by other people. Most of our hires have been hired between a year and few months ago (company is very young by itself).

What is the usual process for me is that I discuss the general direction and required features with top-level management, who is entirely nontechnical and make a roadmap in my head with plans for the "subprojects" which are more or less self-contained units of work, their time estimates and relative priorities with respect to company-wide deadlines.

Based on the last two, I dispatch the tasks to relevant people, waiting when they finish previous tasks. I try not to stress people with too many tasks at once, but treat "tasks" more like a priority queue, where when a person becomes available a current highest-priority task is taken out from a queue and assigned to a person, taking into account personal technical strengths and weaknesses as well.

Most of the time, when giving a task to a person, I already have solution implemented "in my head" and the process mostly revolves around me explaining the relevant part of the codebase to a person and detailing the solution I've envisioned with special emphasis on the parts where a mistake is more likely to be made. After the implementation is done, I take part in testing and perform a code review before merging the code in the production branch.

Sometimes I wish I would give people more freedom, but on the other hand maintaining project coherency and keeping a single direction for the whole team I feel requires for me to make final decisions quite often. I plan to hand off ownership of certain "modules" in some time in the future, but first I'm waiting for deeper understanding of the codebase to develop in the reports.

On the outside, to me, it seems that the process works. People are not complaining, team makes progress, features are done on time and seem to be of satisfactory quality. But like you can read above, I'm base strongly on detailed technical knowledge and basically "planning the work ahead" for the people.

I would really appreciate if anyone could share their experience with making that transition.

I would suggest to you that perhaps a good place to go from where you are is to start getting input into your solution from your new team mates. This allows you space to guage their quality, and make them feel like their input is important, as time moves on, you will then be able to understand where the good people lie, and hopefully allow you to give them more control.

This is the kind of thing that will probably lead to your team being able to grow and feel empowered, and hopefully mean that you can take more time to carry out more managerial responsibility, and give you trust in your team. A secondary advantage is that you let go of being the some holder of all knowledge, which could burn you out in the long term.

Also, perhaps allow code reviews in both directions, as it means that you can see how your input had made them look at other people's code and choices, hopefully giving your business the ability to self manage and to ensure that practises are followed consistently, even if your eye is not on the ball at all times.

This kind of thing had helped me make the transition, although I have to admit that taking my eye of the ball sometimes for too long has led to bad code in our projects and codebase. But that's where you go back and share that with your team, and those that may need greater support. Just remember you are one person, so don't expect to carry out all the work by yourself, empower those around you and give them greater fulfillment over time.

Thank you very much for sharing. I can see quite a few very valuable suggestions here. I'll try incorporating that in my way.

I'm basically the same, maybe a little less on the actual technical direction. What I feel is the biggest disadvantage is that you are the bottleneck for anything to move forward. I'm not sure yet on how to solve that.

A few changes you could try: - have the developers make their own estimates - instead of explaining all relevant existing code, only point to where the relevant parts are or what terms to search for) - if there is a designer involved in the features, try to get them better at making specifications, so developers can work directly with the designer instead of having you in between doing 'translation'

I don't have much more experience as a manager than you do but here are some thoughts. 1. Share the roadmap with your team once confirmed by management 2. Don't force your implementation on the team but let them come up with it and use it as long as it is good enough 3. The time will never come that you feel that your reports are ready for hand over - it will only come by necessity when you are asked to take on more responsibilities so that you have no choice but to hand off this work. So, you may as well start the hand over today as there will never be a better time.

Some of your reports have a year of experience in your code.

1) Do they not propose tasks for bug fixes and refactors?

2) Are engineers encouraged to propose their own solutions?

3) Do you only assign tasks you know how to do yourself?

1. Yes, that happens, although constitutes around 10-15% of work being done.

2. I am certainly listening to any suggestions, but don't necessarily actively encourage it before proposing a solution. Perhaps this is a direction I need to move towards.

3. Mostly yes, as overwhelming part of the complexity just comes from knowing how various parts of the system interact. From time we have an open-ended 'research' (where the outcome is not known upfront) project, but these have a very mixed success rate and tend to overextend the time budget.

You say it takes over a year for people to understand your whole system?

I'd recommend looking into why the ramp up time is so long.

Especially if you only assign tasks you know how to do, you are likely hampering your systems ability to become simpler.

For example, recently we took away 1000s of lines of nuanced code by using an out of the box cloud service (which none of us knew how to use). It offers a similar interface, and it's cheaper and easier to use. Took a week to play around and research if something else was more appropriate, took another three weeks, and we deleted 10% of our code.

I think you've confused project management with management. The two are not the same thing.

He's a line manager. What do you think he should do differently?

Cultivate a team spirit? You tell me.

It's your objection so you tell me, if you actually know what you are talking about.

You should think about how your behavior on HN might impact your reports.

I gather those who report to you are on the junior side?

Junior to mid-level.

Well, the real answer is years of on-the-job experience, but to give you a super-brief version:

It's a common pattern that new managers want to treat direct reports as a set of extra hands. That's fine for the purpose of getting code out the door when developers are junior, but it's irritating at mid to senior level, and it doesn't help anyone grow or think for themselves. Your job is to train them to do those things.

Ask questions. Wait for the answers. Then ask follow-up questions to help them identify problems with their solutions. Self-discovery is more powerful than being told the answer.

Think about their career growth. Ask them about what areas they want to grow in and then try to give them those things.

Fill in the gaps on the team. Let others fill the gaps where they can.