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

How I build software quickly

evanhahn.com

Post reply on HN
Print view View original

121–130 of 215 posts

Re: How I build software quickly

#121

Post by jimbokun »

hamdouni wrote: post #39

When possible, I try to use real data for both volumetry and heterogeneity testing. It helps reveal unknowns in the problem space that synthetic data might miss.

This is very important and requires some foresight when the real data is personally identifiable information, private health information, etc.

It's possible, but requires designing a safe way to run pre-production code that touches production data. Which in practice means you better be sure you're only doing reads, not writes, and running your code in the production environment with all the same controls as your production code.

Re: How I build software quickly

#122

Post by aatd86 »

jimbokun wrote: post #102
aatd86 wrote: post #40

Earlier quoted context omitted.

I don't think anyone would advise to do everything from scratch all the time. It's mostly about libraries vs opinionated frameworks. No one in their right mind would say: just use the standard library but I've seen it online. That discourse is not helping. I think people get this miscontrued on both sides. A set of reusable, composable libraries would be the right balance in Go. So not really a "framework" either. I…

> No one in their right mind would say: just use the standard library but I've seen it online. Yes but...sometimes the proper level of abstraction is simply a good HTTP library. Where the API of your application is defined in terms of URLs, HTTP methods, status codes, etc., the http library from the Go standard library might be all you need (depending on other requirements, of course). A real life example: I needed a…

I don't dispute that. But in general you need sessions, you need a few middleware to, for example, handle csrf or gzip compression of the response, auth, etc. Telling people to juste use the standard library doesn't help. Of course it is available. But often there is a need for more.

Re: How I build software quickly

#123

Post by mackeye »

pandemic_region wrote: post #32
ChrisMarshallNY wrote: post #30

I've found that a "rough draft" is pretty hard to maintain as a "draft," when you have a typical tech manager. Instead, it becomes "final ship" code. I tend to write ship code from the start, but do so, in a manner that allows a lot of flexibility. I've learned to write "ship everywhere," even my test harnesses tend to be fairly robust, ship-Quality apps. A big part of that, is very high-Quality modules. There's alwa…

Tangent, is it a Swift thing to have "* ################################################################## / comment markers ? It becomes quickly very visually dominant in the source code: > / ###################################################################################################################################### / // MARK: - PUBLIC BASE CLASS OVERRIDES - / ###############################################…

i see lots of python with blocks like

    ###############################################################################
    ############################### LIBRARY IMPORTS ###############################
    ###############################################################################

    import sys
    from pathlib import Path
(not in this case but) it helps me for long files where modularization would be inconvenient

Re: How I build software quickly

#124

Post by physicsguy »

jimbokun wrote: post #102
aatd86 wrote: post #40

Earlier quoted context omitted.

I don't think anyone would advise to do everything from scratch all the time. It's mostly about libraries vs opinionated frameworks. No one in their right mind would say: just use the standard library but I've seen it online. That discourse is not helping. I think people get this miscontrued on both sides. A set of reusable, composable libraries would be the right balance in Go. So not really a "framework" either. I…

> No one in their right mind would say: just use the standard library but I've seen it online. Yes but...sometimes the proper level of abstraction is simply a good HTTP library. Where the API of your application is defined in terms of URLs, HTTP methods, status codes, etc., the http library from the Go standard library might be all you need (depending on other requirements, of course). A real life example: I needed a…

Look, I'm not for a moment suggesting that a proxy application would be a good fit for Django (or even Python). I'm talking about 'building a full stack web application in a reasonable amount of time, with auth, with a database, etc. etc.'

Re: How I build software quickly

#125

Post by marcosdumay »

nakovet wrote: post #88
kukkeliskuu wrote: post #22

In recent years, I have learned how to build sufficiently robust systems fast. Here are some things I have learned: * Learn one tool well. It is often better to use a tool that you know really well than something that on the surface seems to be more appropriate for the problem. For extremely large number of real-life problems, Django hits the sweet spot. Several times I have started a project thinking that maybe Djan…

> Forget Celery How do you do background job processing without Celery? Every app/website I ever developed required some sort of background job processing, for Python I use Celery, Rails I use Sidekiq, Node.js I use Faktory. One of the biggest drawbacks (at least until a while ago) was that setting this up had to be a hacky webhook call to your own app that allowed up to N seconds request/response.

You write the demand to the database, and have a worker process execute it. Exactly like you'd do with celery.

Celery is a solution to scalability, not to any business problem in particular.

Re: How I build software quickly

#126

Post by physicsguy »

omnimus wrote: post #64
physicsguy wrote: post #42

Earlier quoted context omitted.

I think Rails is stiff competition, it's just I prefer Python.

Laravel/PHP world is also not bad. It gets bad rep but for CRUD apps the PHP model of every request being isolated is pretty great.

I last touched PHP when you sprinkled it in between HTML (and deployment was FTP-ing it to a server) so I'm well out of date with that though I've heard people say that it's quite nice nowadays.

Re: How I build software quickly

#127

Post by alphazard »

softwaredoug wrote: post #109

Isn't the current layoff-heavy tech world the biggest threat to software quality and engineer productivity? The perpetual looming threat of layoffs, the need to deliver wins ASAP, stifles creativity, punishes experimentation, and pushes people to burnout. It forces people into groupthink about topics like AI. Nobody can say the emperor has no clothes (emperor being leadership or the topic du-jour) Forget LLM coding,…

The biggest threat to software quality, has always been and will always be that consumers don't pay for quality.

Consumers that have good taste (or at least perceive differences in quality) are not numerous enough to support new products that differentiate themselves only with quality. And they (the consumers) are not successful enough in their own enterprises to pay extra for better quality products.

It's easier to find examples where people do pay for quality outside of software. Look at the spectrum in quality available for vehicles or household appliances.

Re: How I build software quickly

#128

Post by physicsguy »

jimbokun wrote: post #98
physicsguy wrote: post #34

Earlier quoted context omitted.

There's an almost pathological resistance to using anything that might be described as a 'framework' in the Go community in the name of 'simplicity'. I find such a blanket opinion to be unhelpful, what's fine for writing microservices is less good for bootstrapping a whole SaaS app and I think that people get in a bit too much of an ideological tizz about it all.

In my experience frameworks (in contrast to "libraries") add complexity making your application harder to understand and debug once you get past the initial prototype. Also, by their very nature they almost require you to write a program of a minimum size even when a simpler program would do to solve your problem.

> Also, by their very nature they almost require you to write a program of a minimum size even when a simpler program would do to solve your problem.

I'm not sure I agree, sure they require you to pull in a large dependency, and that might not be good for some use cases (particularly microservices) where you're sensitive to the final size of the image but for e.g. with Django you get spawned a project with settings.py which configures your database, middleware, etc. and urls.py which configures your routes, and then you're really free to structure your models and endpoints however you like.

Re: How I build software quickly

#129

Post by williamdclt »

nakovet wrote: post #88
kukkeliskuu wrote: post #22

In recent years, I have learned how to build sufficiently robust systems fast. Here are some things I have learned: * Learn one tool well. It is often better to use a tool that you know really well than something that on the surface seems to be more appropriate for the problem. For extremely large number of real-life problems, Django hits the sweet spot. Several times I have started a project thinking that maybe Djan…

> Forget Celery How do you do background job processing without Celery? Every app/website I ever developed required some sort of background job processing, for Python I use Celery, Rails I use Sidekiq, Node.js I use Faktory. One of the biggest drawbacks (at least until a while ago) was that setting this up had to be a hacky webhook call to your own app that allowed up to N seconds request/response.

DB-based queues are pretty common (see outbox pattern). You actually don't have much choice but an outbox in your relational DB anyway, if you want the job to be enqueued transactionally.
Post reply on HN