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 दिन पहले·0 comments

Built to benefit everyone: our plan

openai.com
13 points·by j4mie·पिछला माह·4 comments

The OpenAI Deployment Company

openai.com
42 points·by j4mie·2 माह पहले·33 comments

Perhaps not Boring Technology after all

simonwillison.net
12 points·by j4mie·4 माह पहले·2 comments

Msgvault: fast private email archive and search system

wesmckinney.com
52 points·by j4mie·5 माह पहले·8 comments

The Third Audience

dri.es
1 points·by j4mie·6 माह पहले·0 comments

Django RAPID Architecture, a guide to structuring Django projects

django-rapid-architecture.org
6 points·by j4mie·7 माह पहले·2 comments

Abundant Intelligence

blog.samaltman.com
87 points·by j4mie·10 माह पहले·128 comments

comments

j4mie
·5 माह पहले·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 माह पहले·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 माह पहले·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!