Warpspire

Beat me to it.

Although I discovered recently that someone had written a Trac backend plugin for Git, which rules. Trac kicks the living shit out of every other issue tracker I have ever seen. You should look into Trac and/or Trac integration regardless of what VCS you us; all useful VC/SCM systems appear to be supported nowadays (alas, no Visual SourceSafe)

http://trac.edgewall.org/

Trac kicks so much ass. Moving to Trac legitimately made my hobby site real amounts of money because people entrusted us with more goodwill as a result of our quicker responses and better communication under Trac.

OOOH LOOKY HERE! A trac-lighthouse comparison:

http://warpspire.com/tipsresources/web-publishing/lighthouse-the-bug-tracker-youve-been-looking-for/

AND someone produced a Trac-Lighthouse mirroring tool (not unlike the very useful git-svn SVN-Git mirroring tools):

http://github.com/shayarnett/trachouse/tree/master

This is just too awesome. Maybe GitHub is truly The Way. I haven't been involved with a Big Project on GitHub yet, only Google Code, so take the following with a metric fuckload of NaCl please.

My experience with Google Code has been closest (in terms of communication and transparency) to that of running my own Trac installation. I assume they're converging towards Trac simply because it's the lowest-effort option at a Python shop with an SVN-centric offering.

Github is neat but I have begun to wonder if Git and its toolchain isn't a little discouraging for…

Thanks very much for a thoughtful reply and link to your article. I look forward to reading it.

As it turns out, I shared that very same article in the Datastar discord the other day! Here's some other good ones that I found while digging into the topic, for anyone who cares.

* https://warpspire.com/posts/url-design/

* https://blog.jim-nielsen.com/2023/examples-of-great-urls/

* https://www.w3.org/Provider/Style/URI

* https://www.hanselman.com/blog/urls-are-ui

I strongly agree that good urls are very important. But I don't see how D* prevents correct urls/history at all... You can click anchor links just fine for pages that are genuinely separate pages. If its just a sub page, filter etc, then i think in many cases it should only swap into the dom without updating the history.

Moreover, am I wrong to think that if you use hx-boost to swap in fragments, then the URL that gets updated/saved in history wouldn't actually load the same page if you loaded it from a bookmark? That wouldn't happen with non-boosted anchor links.

Anyway, I'm not the best person to take up this argument. If you are interested at all in some respectful debate on the topic, it would be great if you came by the datastar discord where there's definitely people who would be better able to engage with it. I'd be eager to observe from the sidelines

Thanks for the comment, I’m glad you like it :)
The shorthand one is a really interesting one; it takes while to kick the habit and be purposely more verbose, but you soon get tired of undoing previously accidentally-set styles.

> Do you find indenting descendant selectors helpful?

Oftentimes yes; it can give a new developer more of a clue of the markup structure that a previous developer intended to be used. I can see at a glance that `x` needs to be in `y` but `a` needs to be a sibling of `b`. Of course you could just glean that yourself by looking at and reading all the selectors individually, but it’s nice to get an idea of structure at a glance.

> For your comments, do you adhere to CSSDoc or any particular convention?

Nothing official; I have my own habits but no documented standard. I like the look of http://warpspire.com/posts/kss/ though :)

H

Deep linking is perfectly possible in apps. The !# hasbang is ugly, yes, but the HTML5 History API corrects this with the ability to pushState, replaceState and popState without necessarily having to deal with hashes.

Moreover, this style of linking matters most with publicly available data. For private data, such as the stuff I'm working on storing in the browser with IndexedDB, having a public link isn't necessary for data that's not publicly available. I of course want to support browser history/links in full (see http://warpspire.com/experiments/history-api/ for an example of what's possible) but my point is that when apps are personalized there is not always a need for a link that can be shared across the web.

If I wanted to prognosticate about our web-based future I'd look beyond vanilla hyperlinking and at Web Intents instead.

I've always found that documentation is a skill on it's own. You need to learn how to say something efficiently while answering as many questions as you can. If it's too much people won't read it, if it's too little then it's not useful.

Also learn how to ask questions, you know your project inside and out, try to go to someones position of not knowing anything. I always find stuff that seems so simple at first but then later realize that most people wouldn't know it or connect the dots because they don't know the project.

Here are some resources I've looked at.

https://jacobian.org/writing/what-to-write/

http://ericholscher.com/blog/2014/feb/27/how-i-judge-documentation-quality/

https://www.braintreepayments.com/blog/api-where-to-begin/

http://warpspire.com/talks/documentation/

Every time I see posts like this, I come back to warpspire's "Dumb Software:" http://warpspire.com/posts/dumb-software/

"But wait until you see the light! Software today is intelligent! Asynchronous front ends generated from esoteric scripting languages running on clusters of distributed virtual machines around the globe! Death to repetition! It’s more productive! It’s scalable! It’s fault tolerant! I followed the light and it only ended in darkness."

I also don't understand comments like "we can make drastic changes in the UI without any change on the backend"

In Wordpress or a Rails App, I can change the entire UI without having to touch any "backend" code (controllers, models, functions, etc). Am I missing something here?