Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Ask HN: What overlooked class of tools should a self-taught programmer look into

news.ycombinator.com

Post reply on HN
Print view View original

81–90 of 416 posts

Re: Ask HN: What overlooked class of tools should a self-taught programmer look into

#81

Post by astrobe_ »

pickdenis wrote: post #75
shavenwarthog2 wrote: post #68

Earlier quoted context omitted.

In 2019 Makefiles are a useful tool for automating project-level things. Too often webapps will require you to install X to install Y to run producing artifact Z. Since Make is old and baked and everywhere, specifying "make Z" is a useful project-level development process. It's not tied to a language (e.g. Tox) nor a huge runtime (Docker). Make is small enough in scope to be easy, and large enough to be capable witho…

> The big downside of Make, alas, is Windows compatibility. You'd have to give me a _very_ compelling reason to support developers who use Windows, when Windows lacks these essential tools. Besides, don't people who develop on Windows live in WSL?

I've compiled a thing or two with MSYS2.

Re: Ask HN: What overlooked class of tools should a self-taught programmer look into

#82

Post by theossuary »

bb88 wrote: post #64
d0mine wrote: post #43

Earlier quoted context omitted.

fabfile.py (Fabric) could be used as a Makefile in Python. If you don't ever need to ssh to other machines ti run your tasks, you could use pyinvoke library directly (tasks.py). https://www.fabfile.org/ It is easy to add command line arguments to the tasks, configure them using files (json, yaml), environment variables, to split the task definitions into several modules/namespaces.

Having used fabric in the past, I've always found it just as easy to use a shell script and make files. There's always some level of bootstrapping a project (installing packages/software, compiling libraries and dependencies) where it's easier to just to write a shell script than to program python to do. E.g. How do you get fabric installed on a system? There's also been this longevity of sorts that Make seems to hav…

I've been moving away from using shell scripts in a tools/ directory to using Python Invoke (http://www.pyinvoke.org), which is the library underlying fabric.

I used bash scripts for years, but for a lot of reasons made the switch:

- It was always painful to create small libraries of functions used across multiple scripts in a project

- It's difficult to consistently configure them with per-user settings. I've written bash implementations of settings management, Invoke handles this for me.

- I'd still have to reach for Python whenever I needed to do anything with arrays or dicts, etc.

- Getting error handling correct can be a chore

Invoke has a lot of nice to haves to:

- Autogenerated help output

- Autocomplete out of the box

- Very easy to add tasks, just a Python function

- Easy to run shell code when needed

- Very powerful config management when needed

- Supports namespacing, task dependencies, running multiple tasks at once and deduplicating them

It's not perfect, but it's a lot better than my hand rolled scripts were.

Re: Ask HN: What overlooked class of tools should a self-taught programmer look into

#83

Post by ChristianGeek »

pickdenis wrote: post #75
shavenwarthog2 wrote: post #68

Earlier quoted context omitted.

In 2019 Makefiles are a useful tool for automating project-level things. Too often webapps will require you to install X to install Y to run producing artifact Z. Since Make is old and baked and everywhere, specifying "make Z" is a useful project-level development process. It's not tied to a language (e.g. Tox) nor a huge runtime (Docker). Make is small enough in scope to be easy, and large enough to be capable witho…

> The big downside of Make, alas, is Windows compatibility. You'd have to give me a _very_ compelling reason to support developers who use Windows, when Windows lacks these essential tools. Besides, don't people who develop on Windows live in WSL?

Nope. I develop in Python, Java, and Kotlin on Windows and never touch WSL. Make is available natively through Chocolatey (a Windows package installer), but I prefer Gradle.

(I also write code to run on Linux, but still prefer Gradle.)

Re: Ask HN: What overlooked class of tools should a self-taught programmer look into

#84

Post by pickdenis »

agentultra wrote: post #69

Formal methods. It took me nearly a decade of working in distributed systems to be introduced to TLA+ and other tools in this space. Until then my knowledge had been built from textbooks describing the fundamental data structures, algorithms, and protocols... but those texts take an informal approach with the mathematics involved. And since I was self-taught I was reading those texts with an eye for practical applica…

> the single-biggest booster for me as a practitioner.

Can you instantiate this claim with an example? I'm somewhat knowledgable in both math and computer science theory but have yet to feel as though my math background has helped me in practical CS.

Re: Ask HN: What overlooked class of tools should a self-taught programmer look into

#87

Post by gamegod »

IDEs - A proper work-grade IDE like Visual Studio will have some tools built into it that will save you tons of time. Features like "Edit & Continue" have saved my bacon many times by making intractably difficult bugs in algorithms much easier to understand because you can experiment with your code on the fly.

There's also some more common features in most IDEs like being able to jump between symbols that saves a lot of time day-to-day.

If I'm interviewing you and you say you don't like using an IDE or a debugger, that speaks to your work experience, your productivity, your self awareness about your productivity, and really puts an upper limit on the difficulty of the problems you've had to solve.

Re: Ask HN: What overlooked class of tools should a self-taught programmer look into

#88

Post by aasasd »

caust1c wrote: post #76

Heh, funny that you mention that ZMQ is overlooked. While often though of a message passing library or serverless queue, Zero MQ has some pretty severe limitations that implementers fail to consider. To be clear, I think it's an amazing library which is unmatched in its performance, but it comes at a cost: reduced reliability. ZeroMQ will drop messages in a number of situations. The library does not handle delivery g…

Yeah, every new user has to learn that ZMQ is not a proper queue, but simply a network library and protocol. How is it even possible to bungle the name so badly and then do nothing about it for twelve years?

Re: Ask HN: What overlooked class of tools should a self-taught programmer look into

#89

Post by pixelrevision »

shavenwarthog2 wrote: post #68
aequitas wrote: post #20

Makefiles. I always dismissed them as a C compiler thing. Something that could never be useful for Python programming. But nowadays every project I create has a Makefile to bind together all task involved on that project. From bootstrapping the dev environment, running checks/test, starting a devserver, building releases and container images. Makefiles are just such a nice place to put scripts for these common tasks…

In 2019 Makefiles are a useful tool for automating project-level things. Too often webapps will require you to install X to install Y to run producing artifact Z. Since Make is old and baked and everywhere, specifying "make Z" is a useful project-level development process. It's not tied to a language (e.g. Tox) nor a huge runtime (Docker). Make is small enough in scope to be easy, and large enough to be capable witho…

Will not be a problem for much longer :) https://www.theverge.com/2019/5/6/18534687/microsoft-windows...

Re: Ask HN: What overlooked class of tools should a self-taught programmer look into

#90

Post by cryptonector »

pandemic_region wrote: post #79
cryptonector wrote: post #66

Earlier quoted context omitted.

PostgreSQL + PostgREST + react-admin == fantastic stack. You can write an entire application in SQL and PgPlSQL but using an HTTP JSON API as the interface with a static and responsive BUI. This allows you to be extremely agile in development and ops (because, e.g., you get to use logical replication). I can't say enough good things about this approach.

indeed if your app is about managing your personal dvd collection, or variants thereof, such anemic UI-to-database tools work very well. Not when there is complicated domain logic involved.

Having built such an application (w/ complex business logic), I have to disagree. But I'd like to hear what problems you've run into.

I would agree that react-admin is a bit too simple, and this stack really calls for a BUI to be built specifically to fit the PostgREST model.

Post reply on HN