140
Coders, what is your workflow on Linux (sh.itjust.works)
submitted 3 years ago by to c/linux@lemmy.ml
137 comments fedilink hide all child comments
 

Hello,

I installed Ubuntu a few months ago on my work laptop and I've been running and loving it since.

However, I am used to VsCode, so this is what I am using in Ubuntu as well.

So I am curious, what kind of coding so you do? And what is your workflow.

I am an embedded firware developper and mainly use C. I am cross compiling my code in VsCode for a FPGA from Xilinx (dual core arm + PL)

Never dove into make files and cmake more than what I needed in the past, but I had an opportunity to learn CMake and build a project from it.

So my workflow is :

  1. Code in VsCode
  2. Build in CMake
  3. Transfer the app through scp on the target with a custom script (target is running petalinux, which is yocto + Xilinx recipes)
  4. Use gdb server to debug the code.

It's a pretty simple workflow, but I'd like to know what you guys are running so that I can maybe upgrade my workflow.

you are viewing a single comment's thread
view the rest of the comments
[–] 5 points 3 years ago* (1 child)

I vehemently dislike coding directly on my workstation and do all of my development in remote VMs via SSH, when possible. My work MBP is a glorified SSH terminal with a web browser. I got my start in the industry with remote SysAdmin stuff so, it feels pretty natural.

For an IDE, I use Neovim, currently with a plugin distribution - Neovim because I got used to the vim syntax as a SysAdmin and the distribution because I can't justify sinking more time into tuning my env for a bit but am intending to scrap it all around the holidays or so.

Most of my work is in Go or Python. At home, it's a mix of CircuitPython, C, and I'm picking up some Rust (mainly embedded for C and Rust). Will be starting to learn Verilog this weekend.

For Go and Python, I tend to lean towards a TDD approach, even if it gets a bit derided by coding streamers.

My workflow tends to be:

  1. Prototype desired functionality to get at least individual parts working.
  2. Start from scratch and rough out any classes/structs and test suite boilerplate.
  3. Start the red->green->refactor loop, giving extra granularity to parts of code that I am less confident in.
  4. Once all intended functionality is implemented, run manual tests (I generally develop tools).
  5. Fix bugs that unit tests failed to prevent or I failed to anticipate.
  6. Repeat 4 and 5 until acceptable.
  7. Prepare commit.
  8. Push commit and receive failure because I haven't fully configured my formatters to clean trailing whitespace and VT100-compatible line lengths.
  9. Push commit again and send for code review.

Currently, my build automation is kinda in CMake. Really, the Makefile is just calling a build in a docker container.

For C, Rust, and Verilog, I'm not yet familiar enough to have yet established workflows.

ETA: I think I just got the same FPGA as you! Xilinx Zync-7020 (Digilent Arty Z7-20).

  • permalink
  • fedilink
  • source
  • hideshow 2 child comments
    •
  • [–] [S] 2 points 3 years ago (1 child)

    Almost the same FPGA, we use the Mars ZX2 from Enclustra which uses the zynq7010.

    The TDD approach is a hard sell to companies because it's hard to quantify what time is saved in the end and the MBAs of this world have a hard time with that.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [–] 2 points 3 years ago

    I think that some companies and devs also have a bad taste in their mouth due to overzealous adopters and policies, along with using mocks that are not necessarily going to maintain parity with their production counterparts. Some things are a bit silly to test and mocks like that are going to introduce future technical debt.

  • permalink
  • fedilink
  • source
  • parent