oh that's kind. i hope they keep the old domain up too though: https://shittycodingagent.ai/

looooooool

hey thanks for sharing this and the kind words :-)

it's my second most used CLI tool after git. thrown together to support my own (and my colleagues') use cases, i'm glad other folks find it handy. would be nice to support more features in it when i find the time.

if you keep your site on github, i found keystatic to be a really nice authoring experience: https://github.com/Thinkmill/keystatic

Thanks for the link. I prefer the simplicity of .mdx files for now. My use case is very basic and Astro already handles it well.

keystatic supports editing mdx files. keystatic is basically a frontend to update files on github, so if e.g. you want to write a blog post from your phone it can let you do that kind of thing.

Oh cool, I see. Didn't get that impression when I first looked. I will check it out!

Comfortable

Not drinking too much

Regular exercise at the gym

"the INTJ may become obsessed with mindless repetitive, Sensate activities" http://www.personalitypage.com/INTJ.html

is this secure by default in rails yet? i find it surprising that these techniques are promoted at the same time vulnerabilities are being publicly disclosed:

https://groups.google.com/d/msg/rubyonrails-core/rwzM8MKJbKU...

I believe the fix for this (checking if the request is xhr) hasn't been committed yet.

Is that completely adequate? There was an earlier round of changes due to attackers being able to forge the .xhr header on requests. (This was the patch set at which Rails started checking CSRF tokens on .xhr? requests; before that, they got a free pass.)

See http://weblog.rubyonrails.org/2011/2/8/csrf-protection-bypas...

Is there a way to check that which can't be faked by altering the browser or a js framework though?

I was under the impression that trying to validate that was ultimately as fragile as checking the user-agent string...

It relies on a header, which can't be set through the attack vector, so it's all kosher.

Since we are on the same page, could you help me in this discussion with nzkoz? https://github.com/rails/rails/issues/11509 we're talking about different things

this rules

started one this weekend, it lets you put image directories in _galleries/ and provides you with resized images. needs work yet before it's generally useful but might be a helpful start:

https://gist.github.com/schpet/5523001

dear scratchpad: http://scratchpad.io/j2la3taRYW#fullscreen

Haha thanks so much!! That is awesome

I really like this, I'm looking forward to digging through the source and finding out how folks set up their django apps.

I came here to comment just this. I downloaded it for fun and was stoked to see manage.py! Interesting indeed to explore others' conventions. I particularly like settings as a module.

One thing I tend to avoid, however (of course this is just my personal taste) is templates in each sub-app. I feel like at that point there are just too many nested directories. I'd rather have one global templates dir for the entire project.

I often-times argue with myself over this. I do agree that one global template dir is nice but it makes the apps less copy-and-paste-able and I feel like Django apps were meant to be somewhat self-contained.

However, sometimes you have so many cross-links between apps in Django projects that taking out a single app to use in another project basically breaks most of the functionality.

There are big pros and cons for doing it either way.

How often do you take an app, drop it somewhere, and never modify it? I stick to "my way" because I always end up modifying the hell out of templates.