I am trying to offload as much of the complex stuff to existing parts of the kernel, like using systemd/cgroups for resource limiting and UNIX sockets for authentication.
I do around 4 to 5 sessions per day which hits the sweet spot for me as I can endure this for multiple months without having to take days off. This comes at the expense of having to start a few weeks earlier to have enough time to prepare for tests compared to cramming 12 hour days the week before
I cannot recommend Phil's Lab [1] enough. He has videos which take you from basically an empty sketch to ordering a finished board in around 2.5 to 3 hours. Some of the most worthwhile content I have found on YouTube to date.
Also, get a multimeter and an oscilloscope. Any oscilloscope will do probably, I have one from Amazon for 30$. For my project, it totally does the job, although you may want to invest a bit more here if you intend to use it for more advanced projects. You cannot believe how many times being able to look at a signal has helped me understand where my problem could be and what might be wrong. It has also helped me figure out what questions I had to ask. For simple projects, you are always going to get there by guessing I suppose, but why make it hard on yourself.
Aside from that, just try things. It is probably helpful to spend more time thinking when you are handling more expensive parts, so you do not burn a couple of them out because of carelessness, but also, don't overthink it.
So, more or less as described, but the order is a little different, right?
Is this an automatic process? Or is it more like someone from the company's energy provider calls them and tells them to shut off some devices? And is there not a potential problem, that if too many shut of at once, you now have a surplus again? Or is it coordinated by one single entity?
While I agree that the idea is good, I imagine that at a point where you are planning to extend your dam by another 20m, you already have to implement the required changes in your foundation and general structure and additionally, turbines and emergency vents have to be upsized for the extended heights. So the only thing you are now missing during build is the extra 20m of dam, as the rest has to be built anyways. This leads back to my initial point of the right amount of over-/underprovisioning..
I am not sure if I understood the second point correctly, but you can obviously tell when a dam becomes too dangerous. This can either be because the foundation has set and you now have increased structural stress, the amount of water has increased beyond the maximum allowed levels or a multitude of other reasons, but they are actively monitored.
I have never been in such a situation (at least not one where the stakes were relevant), so take this with a grain of salt. Blaming under these kind of circumstances might arise because the people who do it:
* Either do not have access to the information necessary in order to develop a sufficient understanding of the problem at hand
* Or are incapable of understanding the problem at hand to a sufficient degree (because the project is too big for a single person to grasp or whatever)
So, they resort to assuming some simplifications in order to make everything understandable to them, but these simplifications are likely to be wrong. Consequently, they start blaming people they think to be at fault under their own flawed model of the situation.
A blame-free culture? Explain the situation to such a degree that the decision making around the root cause is easily understandable for everyone. For example, if a bridge fails, there will likely be experts that identify what has caused the failure. If the decision makers for the bridge now say that due to circumstances they disregarded a certain load situation, because x and y and this is an acceptable argumentation (to whoever is judging the situation), there will be less/no blaming as it is now understandable why things have been done that way.
But at a cultural level? I think that this would require everyone to ultimately only judge situations once they have understood the problem at hand. At that point, why do we even talk to each other? Everything we say is based on incomplete information anyways..
If we run multiple different climate models through some sort of Monte Carlo simulation, I suppose each model would output a different probability of such an event occuring. In the case where all models predict a very low probability, it may be easy to say that it is unlikely. But what if two predict a very low and one predicts a low probability? Is this now applicable and should we build to be able to sustain such an event?
These are hard questions and I currently do not see any way to get better data for the future as the different models still do not agree in many points
And does rain rate mean the frequency of distinct rain events over hours/days or the intensity of a single rainfall?
Just curious, maybe you can shed some light on this
They underprovision and an anomaly happens. Now they are the ones who did everything wrong and should be blamed. The overprovision and nothing ever comes close to the theoretical limit of the structure. Now they have wasted huge amounts of money and again, should obviously be blamed. The easiest way out: Plan exactly to what is considered standard. No one will blame you in either case, even if you know that it is insufficient or stupid.
This is something that will probably hold true in many different industries, the consequences for dams are just a little worse..
University is focused on covering the theoretical aspect of computers with a lesser focus on practical applications - although they are thought to some extent - while FH is more focused on building applications and real-life systems with a smaller focus on theoretical aspects.
The only problem is that FH has long been considered second class and everyone wants to attend university. but in my opinion and based on my experience, many people would be a better fit for FH.
For someone deciding whether to attend Uni or FH, it is often not easy because you cannot guess what you are going to do in your work-life and whether you might enjoy research or you would rather go into industry directly.
Aside from that though, I think it is great that we have different institutions for different audiences with differing goals. Does something like that exist in the United States or somewhere else in the world?
Where I see the problem with all these forms of energy storage is that there is no one efficient approach (yet!) and innovation will come mostly from government funding, so governments decide what they see as the best opportunity.
This seems like its pretty much hit-or-miss and betting on the wrong thing will arguably speed up the development of it but at the same time, we might end up at a point we could have reached quicker and cheaper had we used a different technology.
[1]: https://www.energydigital.com/smart-energy/worlds-largest-fl... [2]: https://aresnorthamerica.com/
Also, where before I often had to go to campus for 1.5hrs, which often meant sitting in train for equally long. Now, I can watch stuff from home and don't have to waste time travelling.
Would you agree or did I just look at the wrong Github accounts?
I heard that the company is pretty controversial, but I find their tech to be very cool nevertheless.
Rocket fuel, to my knowledge, does not contain any of those ingredients. Can someone explain what happened there? Was this planned?
Sure, you could map a knob to a slider or anything really, but it makes the interaction easier
This might be a controversial topic with very different opinions, but what are some tips and trick for people who write code in a work setting, but are not trained software professionals?To give an example: I wrote a lot of automation for a bunch of analysis that run on a daily/weekly basis. I always try to do as much as possible in our data warehouse, but some things just cannot be done there,...
Is the concern speed or memory? Because speed would kind of seem strange, since after changing to the new architecture, they should see a strong decrease in messages being exchanged anyways, right?
Or are go's maps inefficient? Genuinely curious
Generally it looks like this:
1. Get data from a central source (data warehouse/other departments)
2. Transform/combine different sources etc. (mostly with pivot tables)
3. output to a sheet
4. add some sort of automation so it runs on its own the next time
Recurring meetings: This might be more personal preference, but I personally would go for scheduled meetings. Every day might be overkill though. Depending on the size of tasks, every other day will probably be just fine. Many questions will likely come up once actually doing work, so be somewhat available to answer them.
Growth: This is probably a lot harder to do remotely, and also largely depends on the previous experience of your intern. One important thing my mentor taught me early on was how to scope tasks, ask the right questions and when to say no to something.
When someone would ask me to do some report, I would always just do it and not question what exactly I was doing (Because for the most part, I did not really know). It turned out that often times the people asking me for it missed something that I had noticed right away but was afraid to ask. I would end up doing the report twice then.
This obviously comes with experience and once you feel comfortable with the systems used etc., but once you feel your intern knows their way around, encourage them to be critical of requests and always ask questions if they notice something that might be off.
Feedback: I would strongly suggest you do so. But also ask him/her, if he/she would like feedback. This also ties in with the growth aspect. You will need the first few weeks to identify strengths and weaknesses and once you notice a recurring theme, that is something you can give feedback on.
Personal example: I was always trying to finish my tasks quickly and more often than not there were subtle mistakes in there, which were always super trivial to fix, but they were there. In my first feedback session, my mentor told me that he was absolutely astounded by my speed, but would rather have me take more time and be sure to do it correctly than rush it. This is obvious in hindsight, but especially if you want to prove yourself, it might not be clear whether it is better to be fast or correct.
Some general things: - Try to integrate your intern into your daily work life as much as you can. What I especially enjoyed was my mentor asking me questions about a task he had and was not sure how to proceed with it. Even if you do not get useful input at first, it helps your intern feel like actually doing useful work. And at one point he will likely be able to provide actual useful input to your day to day work, so its a win-win.
- This is often unavoidable, but please try to give him/her actual work, not something like "Sort these folders by ascending date" or "Print out 50 pdf's and send them to customers". This depends on whether your intern got hired for a certain project or just a general internship though.
During quarantine I have made an important discovery about myself: Everything I do is somehow related to begin 'productive' or with the goal of me receiving praise for it in whatever way. Espeically now with more free time at hand (which I was initially planning to use for something 'productive or useful'), I just ended up wasting about half of it since I deemed the things I was doing...
For a bad actor, the cost-reward looks pretty low (if we assume a high initial investment like a couple hundred million dollars to approach our goal of data collection in a shorter timeframe), but for a government that is probably totally doable.