HackerTrans
TopNewTrendsCommentsPastAskShowJobs

j4mie

no profile record

Submissions

UK sales of electric vehicles just overtook petrol cars for the first time

carbonbrief.org
6 points·by j4mie·17 giorni fa·0 comments

Built to benefit everyone: our plan

openai.com
13 points·by j4mie·mese scorso·4 comments

The OpenAI Deployment Company

openai.com
42 points·by j4mie·2 mesi fa·33 comments

Perhaps not Boring Technology after all

simonwillison.net
12 points·by j4mie·4 mesi fa·2 comments

Msgvault: fast private email archive and search system

wesmckinney.com
52 points·by j4mie·5 mesi fa·8 comments

The Third Audience

dri.es
1 points·by j4mie·6 mesi fa·0 comments

Django RAPID Architecture, a guide to structuring Django projects

django-rapid-architecture.org
6 points·by j4mie·7 mesi fa·2 comments

Abundant Intelligence

blog.samaltman.com
87 points·by j4mie·10 mesi fa·128 comments

comments

j4mie
·5 mesi fa·discuss
This looks great! Question on the API/CLI - is there any provision for capturing frames (or even streams?) from Homekit cameras, or even triggering events or webhooks based on the cameras detecting motion?
j4mie
·6 mesi fa·discuss
When we bought our house (1950s semidetached) it needed a full electrical rewire. I’m so glad I asked the electricians to run Ethernet all over the house at the same time, including to the ceiling in some rooms for WiFi access points.
j4mie
·7 mesi fa·discuss
Hi, author here. I have been building Django and DRF applications commercially for about fifteen years at DabApps, and this guidebook is an attempt to write down the architecture patterns we have arrived at, for projects that have to survive years of ongoing maintenance.

High level summary:

* We don’t hide Django under layers of abstraction, we just slice it up a bit differently than you would by default.

* Organise code by responsibility (readers, actions, interfaces, data) rather than by app.

* Put most business logic in plain functions, not in fat models or deep class hierarchies.

* Keep views thin: treat GET as "read some data" and POST as "do an action".

* Design endpoints around real frontend use cases (backend for frontend) instead of idealised resources.

* Control queries carefully to avoid performance traps.

Happy to answer questions!