I’ll post some updates with pictures here, or if everything goes wrong, a very whiny post about how much the world sucks. Wish me luck, #pants!
I’ll post some updates with pictures here, or if everything goes wrong, a very whiny post about how much the world sucks. Wish me luck, #pants!
Sagen’s mal Herr @hmans.io, gibt es eine Möglichkeit #pants dazu zu bringen den Avatar cache neu zu laden? Gibt doch recht viele veraltete Avatars mittlerweile in meiner pants Instanz und es sieht nicht so aus als würden die sich noch von alleine updaten. Oder versteh ich hier ein Feature falsch?
Ich glaube, aktuell leider nicht – du müsstest wahrscheinlich in deiner lokalen Datenbank rumdoktorn und die entsprechende Spalte NULLen. Ich mach’ mir für IndiePants eine Notiz, dass das intelligenter mit den Bildern umgeht.
So #Pants != IndiePants? I thought it was supposed to be a rename.
IndiePants is a big new version of Pants, big enough to be its own project on GitHub – when it launches, it will simply replace Pants, without a rename. “IndiePants” is simply a working title; I could have called it “Pants 2.0”, but using a version number simply didn’t feel right.
The name stems from the fact that this new version has significantly improved support for IndieWeb schemas and protocols; in fact, Microformats2 and Webmention are taking center stage now, instead of being an extra in a mostly proprietary environment. Removing the old non-IndieWeb code also allowed me to significantly improve performance and portability.
DIS GON B GUD!
I don’t think there are any beyond those that you can see listed on my Following page (of which many have already been abandoned, unfortunately.) So all in all I would wager that you’re not missing much at the moment.
This is partly my fault, as I haven’t really been driving people towards #Pants a lot lately, the primary reason for this being my ongoing work on IndiePants (which, by the way, is shaping up nicely.) Once I’ve deployed the new code and migrated everyone I can to it, I will get back to pestering people about Pants in every channel known to man (and cat), and it’s going to be beautiful!
Hopefully you’re not disappointed by the currently somewhat minute amount of activity. If you are, I’m hoping to be able to convince you to take another look by the time the new bits are online.
Man, you guys would hate me if you knew what I do at my day job. Remind me to never say anything about it on #pants :p
FWIW, I currently spend most of my working time consulting tech companies that, well, let’s just say they aren’t quite aligned with what I’m doing with #pants.
I don’t consider this a problem. My day job feeds my family, and my spare-time Pants adventures hopefully contribute to keeping the web a sane place for people like myself. I’m in the lucky position that I don’t have to make a project like Pants my day job. This gives me quite a lot of control, which is something I’m enjoying very much. :)
Having said that, I have a couple of ideas how I may be able to exploit Pants commercially (without immediately “breaking” it), but I’m in absolutely no rush to turn myself into a slave of what should just be a fun little punk project.
Let me tell you about the web I want.
I want a web where everything I write is hosted on my own domain, including comments I post about other people’s posts.
I want a web where I can comment on someone else’s posts without having to sign up for their site, forum, or favorite centralized commenting system.
I want a web where I can comment on other people’s posts, even if their site doesn’t have commenting functionality.
I want a web where I can share and express my approval of someone else’s work without having to do it in a walled-garden social network.
I want a web where I can post anything I want, on my own domain. If it’s related to someone else’s stuff, I will notify them; but I will leave it up to them if and how they display it. Maybe they display my comment underneath their article. Maybe they just link back to it. Maybe they ignore it altogether. It’s up to them; it’s their site.
A: “Und, worüber schreibst Du so in deinem Pants Blog?”
B: “Naja, nur davon, wie ich Pants betreibe und das ich es irgendwohin migriere.”
A: “Öhm, macht das sinn?”
Ich finde dein #pants-Blog spitze! \o/
I’ve been working on #pants for 4 months now – on and off, due to intermittent client and/or baby related work load. Still, I can’t believe it’s only been 4 months. Even within this short time frame, the project has gone through so many different iterations. They grow up so fast!
When I started out, I kept saying how I didn’t really know what #pants was and where it was headed. Four months later, I think I have a pretty good idea of what it is, so I thought it’d be fun (and potentially useful) to look back at its development so far and think about what worked (and what didn’t), and which parts of #pants I would do differently if I were to start from scratch. (Which I’m not going to; but maybe there’s a chance to get the most important or interesting bits implemented in the current code base.) Well, here we go.
Open Source from the start: yes, #pants has been open-source from its very first commit, something I’m very happy about. This is a lesson that I learned when working on sloblog.io; when I decided I wanted to open-source the project months after launching it, I realized that I didn’t really want to bother with cleaning up the code (having made the usual mistakes of committing secrets to the code base that should not be public, and other atrocities.) I didn’t want to make the same mistake with #pants.
I need to admit that I have a pretty ambivalent attitude towards open-sourcing my projects. In my experience, most people asking for something to be open-sourced are really asking for it to be provided for free, which is fine, and often to be easily installable on their (sometimes underpowered) servers, which is also fine to ask for, but very hard to achieve with complex software. Giving in to these requests in spite of reservations is a recipe for disappointment, which is one of the many reasons why, in #pants’ README, I’ve been paradoxically telling people not to install it.
And this is where I’m at with open-sourcing #pants right now. I do want to share the code, allowing others to learn, review, comment and possibly hack; obviously, I also do want others to be able to install the code on their own servers, duh; but I do not want to (and can’t) offer much in the way of installation support at this point.
Having said that, please rest assured that actively encouraging people to install their own copy of #pants of course is a cornerstone of its future, but the only officially supported deployment will be Docker-based, and I simply haven’t had the time to prepare decent Docker images.
Rails doesn’t have a great concurrency story; its server processes use humongous amounts of memory; the way gems (Ruby library packages) work is an invitation for unstopped bloat. So why did I pick it for #pants? Even with all these caveats, Rails is the framework that I’ve been using almost exclusively for most of the last decade; with the familiarity gained in this time plus all the amazing Rails gems available, I can whip up something over the course of a weekend that would probably take (me) multiple times longer with any other language or framework. #pants doesn’t have a high number of users yet, and none of them appear to be facing load issues, so I think we should be okay for a while. If #pants gets its 15 minutes and isn’t able to handle them, it’s going to be a fun problem to solve through a reimplementation in another language.
(Ironically, the best fit when it comes to improving #pants’ installation story would have been share-nothing style PHP – just upload the code to your web server and you’re good to go, I guess? But let’s just say that I’m not a fan.)
PostgreSQL vs. Document Databases: Rails uses PostgreSQL as its database, a RDBMS that I’ve recently fallen in love with after years of using MySQL. Seriously, if your app needs a relational database, give PostgreSQL a try, it is great; the extra features (like arrays) it offers allow you to model certain things much quicker and with less code.
However, four months into the project, I now wonder if a document database (aka NoSQL, etc.) would have been a better fit. From where I’m standing, the lack of a strict schema alone is a huge advantage in fast-evolving open-source projects; migrating relational database tables and integrating these migrations in deployment runs isn’t exactly rocket science in Rails, but explaining to users they need to run update scripts (even if it’s just a
rake db:migrate) can be. What I really want users to be able to do is to just update/replace the code (eg. Docker image), and things will just work. This probably one of the most trivial differences between relational and document databases, but here it would make a big difference.
In addition to this, I’ve been lustingly ogling RethinkDB for some time now. I haven’t actively used it in any projects so far, but what these guys are doing just feels and looks right, and I so want to give it a serious spin.
Another option may be CouchDB, which has some views on simplicity that strongly resonate with me, even though I’ve never used it in a real project so far, either.
Binary asset handling: Up to this point, #pants doesn’t really allow you to upload binary assets (post images etc.) beyond your user avatar. I was going to leave the storing of images et al to the users, but I realize now that #pants absolutely needs to support this stuff out of the box; a large part of social networking (and blogging in general) revolves around the sharing of images and other assets, and this stuff should be on the user’s server, so in the long run I can’t really get away with making users upload their stuff to Dropbox et al as I’m doing now.
The problem is that dealing with file uploads has always been and still is tricky, especially with open-source software that you’re expecting people to eventually install on their own servers. I’m using the excellent Dragonfly gem to deal with uploaded images and the like, and it’s easy to configure it to anything from using the local filesystem to putting everything on Amazon S3, but where do you strike the balance between convenience, flexibility and minimal external dependencies? The easiest configuration is to just use the local filesystem, but then you’ll be in trouble once you need or want to add more web servers; also, a bunch of potential hosting options (like Heroku) would not work. Amazon S3? It’s cheap, easy to set up and generally great, but it’s yet another external dependency that you need to set up (and sign up for); also, not everybody is keen on Amazon.
Ideally, I would like to put uploaded files in the same store that is holding all the other data; the database. Storing binary data in PostgreSQL isn’t difficult, but also not trivial. Its Large Objects aren’t natively supported by ActiveRecord, and I wasn’t entirely confident about the workaround-ish Dragonfly plugin that I built at some point; simply serializing files and splitting them up into chunks (by way of dragonfly-activerecord may be more reliable, but extremely smelly in more way than one.
Yes, you could probably hook up Dragonfly to some FTP server easily, but once again, the perfect option would simply work out of the box, using the same database that’s storing everything else. This may be another point in favor of a document database; MongoDB and CouchDB are said to have very solid binary data support (with Dragonfly plugins readily available), and RethinkDB appears to have at least some support, too.
GUIDs, URLs, slugs, oh my: this is really just a technical detail, but a tricky one. In an ideal world, a #pants post would simply have a single, globally unique ID: its URL. However, since post IDs are not supposed to change, this would completely obliterate all SEO efforts, as you could never add or change an existing post’s URL to something that’s more SEO-friendly. Even worse, someone switching their #pants instance to HTTPS would basically change all URLs of all their posts. Ouch.
So I ended up separating URLs from my own flavor of GUIDs, the latter being simply a URL, but without a protocol (eg. a post at the URL
http://hmans.io/foo123 would have a GUID of
hmans.io/foo123.) The idea here is that the URL is allowed to change (both its protocol and path), while the GUID should always stay the same (and, if necessary, redirect to the post’s current URL.)
If this confuses you, I don’t blame you. I’ve never been too happy with this setup; it feels like an overly convoluted solution for a problem that we didn’t really face yet. If I were to start over (or find the time to refactor most of #pants’ code), I would probably just keep two different URLs; one being the ID (staying the same over the lifetime of a post), the other being the human-facing, SEO-friendly URL. This would allow me to get rid of a heap of code converting URLs to GUIDs and back.
Indieweb: #pants is what the indieweb community would call “and indieweb implementation”, but I didn’t quite realize this until several weeks into the project. #pants is now making heavy use of Indieweb protocols and markup, but it didn’t do so from the beginning, and it absolutely should have. I’m not sure how this happened; I’ve been aware of indieweb for a while now, but didn’t think of embracing it with #pants when I started development.
Webmentions everwhere: Webmention is an extremely simple reboot of protocols like Trackback or Pingback and probably the most important thing to come out of Indieweb for #pants. Webmentions allow site A to tell site B that it has published something interesting, like a comment to a post. #pants uses Webmention liberally; when you post a reply to someone else’s post, their site receives a Webmention, allowing them to pull your comment to be able to display it beneath their post; when you follow another #pants site, it is notified through a Webmention; the upcoming Like feature uses it, too.
The great thing about this approach is that this allows #pants to easily communicate with non-#pants sites, as long as they also use Webmention. Once your #pants site receives a Webmention, it will pull and analyze the referenced source URL, no matter if it’s a #pants site, Wordpress, a static HTML page or whatnot, and depending on what it finds there, list the reply/fav/etc. underneath the referenced post. Just like my previous point about Indieweb, I only realized just how great this is very late in the project and would have saved a lot of time embracing it from the start. (Incidentally, #pants was using a very similar setup to allow for remote #pants instances to communicate; I called it a “Ping”, and while I eventually refactored the whole business to simply use Webmention, there’s still a
Ping model and a
Separate post types, pre-rendered body HTML: this is one of #pants’ features (or rather design decisions) that I’m especially happy about. Basically, the stuff that we’ve been using so far – text posts that contain Markdown which is then rendered to HTML – is just one of many (possible) types of post objects that can be published on your #pants site. The upcoming Like feature uses a second post type, and I want to make it trivially easy for people hacking #pants’ source code to add new types (think image gallery posts, reviews, polls, etc.) The great thing is that custom #pants post types will even work on remote #pants servers that don’t have the code powering them, as each post comes with a pre-rendered chunk of HTML that will just be displayed instead. The one thing that I would like to add to #pants is to have not one, but two pieces of pre-rendered HTML; one for the full post, one for the feed views, possibly containing a shorter version of the post.
That’s it for now, I think. I apologize for spamming your network timeline with such a long post! Let me finish this with saying how happy I am that so many people are enjoying #pants already. And remember, if you want to give it a try, here’s how!
In der Hoffnung, mich öfters dazu motivieren zu können, meine Pocket-Liste leer zu lesen, möchte ich die interessanteren Fundstücke an dieser Stelle verbloggen. Ich wette dagegen, dass das funktioniert, aber wer weiß!
Oh, wie bös ist das System: ein hübscher Text auf Zeit Online über Systemkritiker und Verschwörungstheoretiker, dessen Kernaussage man auch abseits des dort geführten Beispiels Xavier Naidoo auf viele aktuelle Diskussionen anwenden kann.
Kicking the Bukkit: Anatomy of an open source meltdown protokolliert den Untergang des Open-Source-Projekts Bukkit, einer quelloffenen (und dadurch mod-baren) Alternative zum offiziellen Minecraft-Server.
Docker and Microsoft: Docker (Inc.) und Microsoft haben eine längerfristige Zusammenarbeit angekündigt, deren Ziel umfassender Support von Docker-Containern in Microsofts Server-Technologien ist. Ein solcher Schritt ist dringend notwendig, damit Windows nicht irgendwann vollends von der Server-Software-Landkarte verschwindet.
Mac App Store: The Subtle Exodus beschreibt die zunehmende Flucht von Entwicklern aus dem Mac App Store. Natürlich sind in erster Linie Apps betroffen, deren Funktionalität nicht mit den Sandboxing-Bedingungen des Stores kompatibel sind; in den meisten Fällen sind dies sehr spezialisierte Apps (z.B. für Entwickler), ob es sich also dabei um einen größeren, gegebenenfalls für den App Store gefährlichen Trend handelt, ist fraglich.
Netflix-Effekt: die plötzliche Liebe deutscher Sender und Filmstudios zu Qualitäts-TV-Serien. Ich selber stehe kurz davor, meinen TV-Anschluss auf ein Minimum zu reduzieren, da ich inzwischen vorrangig über Angebote wie Netflix, Watchever, iTunes oder Kabel Deutschlands Select Video konsumiere (oder einfach die Blu-rays kaufe, ich Romantiker.) Wenn deutsche TV-Sender auf einmal in hochqualitative Formate investieren, werden diese hoffentlich kundenfreundlicher angeboten, als sie mit Werbung durchspickt im Free-TV zu verballern.
Wir fordern den Rücktritt der Bundesregierung ist ein heiteres Video, das seit ein paar Tagen durch die sozialen Netze geistert. Das hämische Gezetere ist natürlich wieder einmal groß, aber wer ein bisschen sucht (es ist wirklich nicht so schwer), findet schnell heraus, dass dahinter der österreichische Youtuber PockhuhnFilm (Twitter) steckt, der sich auf dadaistische Video-Comedy zu spezialisiert haben scheint.
Which version did you update from? r105 didn’t include any major changes to the network timeline from r104 (here’s the diff), so I’m finding it hard to find a reason why this would happen. It’s also hard for me to debug a remote #pants instance, obviously, but if there is a bug, I’m naturally interested in fixing it. Would you be okay with emailing me a dump of your #pants database?
Ich möchte mir ggf. doch bald endlich einen (bescheiden ausgelegten) PC zum Basteln und Spielen (Steam-Krams) zusammen basteln und habe mir mit etwas Unterstützung aus dem #pants-Channel auf Freenode diese Konfiguration erbastelt. Mein Budget: €500, eher als Übung statt aus Notwendigkeit.
Habt ihr dazu Feedback? Ein paar Notizen:
Über Feedback und Vorschläge freue ich mich (solange die Konfiguration mein selbstauferlegtes Budget von €500 nicht plötzlich überschreitet.)
It needs more:
The default of 1GB RAM works fine for small Discourse communities. We do recommend 2 GB RAM for medium communities.
Does it need it for the entire application stack (including database server etc.), or just the Rails app?
As long as #pants is a Rails app, it will probably be similarly hungry for memory. In the (very) long run, I would love to re-implement #pants using something like Elixir/Erlang, or possibly Go. The primary reason for me to use Rails is that right now, as we’re still discovering what this thing actually is, Rails allows me to iterate much faster than anything else out there.
It’s unbelievable how much memory ruby needs to run #pants :P At least not comparable to how much Discourse needs…
I’m not sure if you’re saying Discourse needs more or less memory? How much does it need?
I’m interested in keeping #pants lean, obviously, but Ruby (and Rails, specifically) apps are pretty memory hungry by nature.
In the interest of transparency and managing expectations, here’s an extremely high-level roadmap for #pants. I will be updating this document from time to time to reflect the current state of the project.
Consider the above list (roughly) sorted by priority.
tl;dr Make SEO a bit more important, please! :)
I’m on it. Trust me, even if it’s not the highest priority, it is a priority. Things that are slowing me down:
Not feasible at the moment. In theory, you could just reconfigure your entry in the
users table to use the new host name and keep redirecting your old host to the new one, but some stuff will stop working as expected. For example, people following you will still be polling the
pants.epir.at host. It will redirect to your new
epir.at host just fine, however, the new posts your JSON feel will be serving will not match the expected host name and will thus be discarded.
In order for this to work properly, instances need to be aware of 301 responses when polling and update their locally known records accordingly. As you can imagine, this opens the doors for some interesting attack vectors, so just like with the SEO stuff you mentioned, I need to give it some more time to come up with a good solution that works well.
For the time being, you’ll probably have an easier time creating a new user for your new host and manually migrating (or copying) your existing posts to the new host.
Even though SEO has a lot of similarities with selling snakeoil, URLs really do matter for search engines (and sometimes users).
#Pants should always lookup posts by it’s unique_id and/or slug, but ONLY accept slugs if they exactly match the pre-defined slug. If the slug is invalid, it should use the unique_id to redirect (301) to the correct slug.
Don’t worry, I’m aware of SEO requirements for a solid blogging engine, and I won’t be ignoring them; they’re simply not at the very top of my list right now. I want to do things right, and this is a lot more complex in a distributed system. Consider this: for the SEO effect to work, you’ll want to distribute the full post URL to other #pants nodes (so they can link to it directly, without all the link juice going to a URL that serves a 301). Right now, though, a post URL is defined as the combination of its base URL (protocol and hostname) followed by the post’s #pants ID, which is expected to never change. The URL is used for a whole bunch of lookups, which is why, following this definition, it is not expected to change, either.
For this reason the introduction of human-readable URL slugs (for SEO or whatever reason) also requires the introduction of a human-readable URL (vs. the system-readable URL that we’ve been using so far.)
It’s not exactly rocket science, but it goes further than just slapping another column on an existing database table. Give it some time. :)
Will #pants ever has more descriptive URLs? I am a big fan of more descriptive/readable URL’s :P
The URL of a #pants post is also its (globally) unique ID and thus must not change. It should, however, be possible to use a canonical short-form URL for the ID and have it redirect to a long-form URL containing a longer post slug, so maybe I (or someone) will implement this at some point.
Load more posts