• 1 post
  • 54 comments
Joined 3 years ago
Cake day: October 21st, 2023
  • The tooling around AI should be to improve the quality of the programmer. Not to write the code for the programmer.

    For example if you ask an agent how to scale things well, and best practices in architecture, it will have a lot of resources on it. But that does not mean the code it will produce when you ask it to write a programme will consider and include the best practices it gave you in a separate question. That is the ‘intelligence’ part that LLMs cannot have. If you ask a it to do a certain way it will create it. Context tries to address this by prompting the user to give more, but that is not persistent.

    This is exactly why senior devs finding LLMs works for them, because they know ‘how’ to do it, and they explicitly state it. But at the same time junior devs feel they think the code written by LLM is the ‘best’ way so solve a problem and superior in quality, even if it is not, because they don’t know any better.

    Tooling should be able to help the developers improve their knowledge and skill on ‘how’ to do it. Instead it always focus on writing the code. I want to add that I’m not talking about algorithms. But every aspect of coding, in which the programmer needs to know ‘how’ to do it.

  • The problem is not when I have to rebase. I know how to handle it. But with juniors they approach us only when things are in a really bad situation, where they cluelessly applied some commands they found on internet or from an LLM. Then it is very annoying to sit down and untangle the mess they created.

    And regarding the pushing without fetching, it is usually a different branch. So they won’t incorporate the new changes in the main branch into their working branch, but just push their work into a branch. Again not a big deal. Just annoying.

  • See all this is fine for someone with good experience in git. They know how to solve the screw up. But wih junior devs, who don’t know much about it, they will just get confused and stuck. And one of the senior has to involve and help them solve. This is just annoying because these can be avoided very easily. Until they understand the pattern of how everyone operates with git, it just creates issues.

    To me first time causing this issue is completely fine. I will personally sit with them and explain then what went wrong and how to recover. Most of them will repeat it again, act clueless and talk like they are seeing this for the first time in their life. That is the difficult part to me.

    May be I’m just old school, and a grumpy old person, even though I’m not that aged.

  • So this workflow is needed if you are working on a public, i.e. multiple devs collaborating on a single branch, scenario. But it is much better to avoid this as much as possible. Usually it is a ‘scoping’ issue, where you create a branch that is too broad. For example ‘api-for-frontend’, which is a massive thing.

    But let us say you absolutely have to get multiple devs on same branch, then this workflow is totally fine. There is nothing wrong in it.

    In our org we prefer to delete the branch after merge. In a way it says ‘this branch is closed’. This is to encourage devs to define smaller and more logically scoped branches.

    I want to take this opportunity to say that, branch is just a label on a commit, with some additional functions. Once you start focus on commits and lineage of the commits, then branches become some what irrelevant.

  • Yeah.But many of them are extremely annoying. Specifically screwing up rebase. It is recoverable, but very annoying.

    That said I have seen juniors make two other common mistakes.

    1. Pushing your commit without fetching
    2. Continuing on a branch even after it was merged.

    I’m fed up with these two. Yesterday I had to cherry-pick to solve a combination of these two.

  • Hosting site in your local machine is tricky. It depends on how your ISP configured your network and most of the time you will be under CGNAT. Which means you will not have a unique public IP, but a shared one. Similarly your IP will be dynamic which will need additional configurations. Nowadays it is very difficult to host a site on local machine directly.

    Edit: Checkout if your ISP provide unique IPv6 for your machine. This will not have issues of CGNAT, but you will have to setup DynamicDNS (DDNS) to accomate the changes in IP.

    Edit: If there is CGNAT and you don’t have IPv6, then you need ‘NAT Hole Punching’. Usually services like Tailscale, ZeroTier, Amnezia, Innernet, v2ray, etc. are needed for that.

    One thing you can try is Tailscale Funnel. Fair warning, bending your head around functioning of Tailscale is not trivial, and you will have to spend some time to properly understand and set it up.

    If you prefer a simpler route, free hosting of a static site is your best bet.

    Netlify is the go to solution if you are familiar with Git. I used to have my portfolio up there. Another option is, as you mentioned, Github Pages.

    Vercel is the another common one people use. But it might be a little more tricky to get it working, because it focus on front end framework like Next.js.

    Checkout Cloudflare Pages too. Very much similar to GitHub Pages, but with the performance and reliability of Cloudflare.

    Heroku is another thing people used in the past. I think the free tier got limited nowadays.

    Good luck with your adventures.

  • I have a particular feeling which I want ask you all.

    In the last few years, I have seen that some new cyber security firm will come up with a new ‘novel’ security vulnerability, and media will give those ‘vulenrability’ huge coverage, but in the end in reality that vulenrability is just of academic interest, and without any real life implications?

    There was a ‘logo fail’ vulnerability, then GitHub ‘leaking’ credentials (it was bad narrative built around a GitHub feature), and so many more.

    All I see is fear mongering with sensationalised media coverage. Am I the only one feeling this way?

  • It didn’t work like that for me. I must admit I didn’t dig deep to clearly see what is the problem. So my setup had a Windows Pc, a Raspberry Pi 5, and an Android phone, sharing a folder which had notes.

    Whenever I save any changes in Windows machine, the android used gets updated without much issue, but the Raspberry Pi caused conflicts. When looked at the time stamps they were different and it looked to me like the Raspberry Pi 5 Syncthing is sending the old file as new one, because of the save time.

    It read somewhere the issue is with how time is handled in Rasberry Pi. So I disabled the Raspberry Pi Syncthing and went on, because that was not really needed.

  • First and foremost Syncthing is not a ‘backup’ utility. Using it for backup is not at all recommended. Especially if you are dealing with Android or Raspberry pi, because the way clock / time works in these systems are pretty weird and create sync conflicts. So don’t.

    Now to the solution. For backup, use a proper backup solution like Kopia. Modern solutions support browsing the snapshots created as backups. Also creating periodic snapshots ensures better redundancy and better chance for disaster recovery.

    Now if you will not use it for backup, take a look at ‘Round Sync’ available in F-Droid. It’s an application built around the execptionally good app, ‘rclone’. It is some what similar to Syncthing, but designed in a very different way. Also it is more difficult to configure to copy the files to PC.

    I also wanted to mention that I have used Syncthing for many heavy lifting jobs and never faced issues with it. It is a feature complete app, with the philosophy of doing only one thing and doing it perfectly. So if you run into any issues, do reach out to forums or devs. They will definitely help you.

  • As I mentioned it is to reduce dependency on CI tool. You may have to shift the tool in the future and if you use a lot of commands specific to the CI tool, that is going to be a nightmare.

    Ansible is agent less and only needs SSH access. You can SSH into your local system, from the same local system. Need to add few entries in your SSH config and known_hosts. Essentially everything in Ansible are shell commands. So you are not really that much locked into Ansible.

    On the question,

    Does that make running it locally easier?

    If you mean making it easier compared to remote, on the surface level, the answer is ‘no’. But it makes CI pipeline easier to run independent of your environment. Ansible is here to reduce dependency on a specific tool.

    Bonus point is you can also create a working but basic CD system with Ansible.