I like kotlin SpringBoot apps deployed to k8s. Go apps for custom k8s operators/controllers.

  • 11 Posts
  • 41 Comments
Joined 1 year ago
cake
Cake day: June 17th, 2023

help-circle

  • I find it very difficult to recommend generative ai as a learning tool (specifically for juniors) as it often spits out terrible code (or even straight up not working) which could be mistaken as “good” code. I think the more experienced a dev is, the better it is to use more like a pair programmer.

    The problem is it cannot go back and correct/improve already generated output unless prompted to. It is getting better and better, but it is still an overly glorified template generator, for the most part, that often includes import statements from packages that don’t exist, one off functions that could have been inline (cannot go back and correct itself), and numerous garbage variables that are referenced only once and take up heap space for no seemingly no good reason.

    Mainly speaking on GPT4, CoPilot is better, both have licensing concerns (of where did it get this code from) if you are creating something real and not for fun.




  • I have been using “gaming” keyboards for coding for ~10 years now. The only thing to be wary of imo, is keebs that have “extra customizable keys” on them and break conformity from a standard layout. Depends on the device, but Logitech will call them “G keys”, for example, and often stick them on the far left of the board, left of tab/caps/L shift. Makes life a lot more difficult if not gaming.

    Outside of that, I think calling something a “gaming” keyboard is more of a marketing tactic to up the price. It’s hard to not recommend mechanical, but that sounds out of budget and often hard to do wireless/bluetooth, but personally I think mech is the top priority.

    What I have seen a lot of peers do is wait to see whatever keyboard the get in office, then buy the same one for home for consistency, rather than dragging a personal one back and forth. Often companies will offer basic boards like logitech K270, K350, or K650. Not amazing, not terrible, and most likely fit in your described criteria.







  • I prefer a similar workflow.

    I am a major advocate of keeping CI as simple as possible, and letting build tools do the job they were built to do. Basic builds and unit/component testing. No need for overcomplicating things for the sake of “doing it all in one place”.

    CD is where things get dirty, and it really depends on how/what/where you are deploying.

    Generally speaking, if integration testing with external systems is necessary, I like to have contract testing with these systems done during CI, then integration/e2e in an environment that mimics production (bonus points if ephemeral).


  • The most difficult generalisation step is going from one to two. Once you’ve generalised to two cases, it’s much easier to generalise to three, four, or n cases.

    🥇

    Although it seems to ignore things like sidecar containers to support the application locally (rather than needing to do a full install of a database tech, for example), I really like the point being driven.






  • In my opinion, it really depends on what type of place you would want to work. There are a lot of options out there, but (specifically for SRE) “cloud knowledge” is a must most places.

    I would consider someone with an SRE title more ops than dev, and wouldn’t expect much in terms of writing code. I would more expect things like advanced knowledge of availablility, reliability, performance and observability on whatever cloud provider is being used. A Site Reliability Engineer is responsible for realiability of the deployed site, so it is dependent on the site/company on what the actual day to day would look like.

    This isn’t to say you wouldn’t have a place in DevOps with your current skills. However, it may be an easier route to start more on the dev side than the ops side as, in my experience, ops are harder to learn generically because every shop has different processes and operations.

    The dev side includes things like you mentioned (e.g. build/test execution/package/artifact publish/code release) and then mixes heavy into ops during deployment which then turns into SRE type stuff when the app is deployed to a real place. Often the dev side is done by people with Software Engineer type titles (potentially a DevOps team), and may even be done directly by the developers themselves.

    A lot of these processes include a developer needing to execute locally as well as repeatable execution by an automated system of some type (CI). Linux and bash knowledge is very useful for these types of things, as most of the time end deployment will be on a Linux distro, although development happens on OSx or Windows.

    The industry is already trying to change buzzwords, from DevOps to DevSecOps, so it is never bad to know security as well. Things like security vulnerability detection and remediation are very valuable and part of the “shift left” in terms of software delivery.

    You are welcome to read my comment history to see my feelings about python in DevOps, but they are not positive, and should just use bash, unless it is actually a python shop and other people know how to use python, or else it will most likely become a security vulnerability in and of itself.