W1siziisijiwmtqvmdyvmjkvmtuvmtkvmjkvmjqxl2htyw5zx2j1zxjzdguyx3nxdwfyzs5qcgcixsxbinailcj0ahvtyiisijmwmhgzmdajil1d?sha=be2ba8cb

Aber ich habe noch immer kein gescheites Setup gebaut, komme einfach nicht dazu. :-(

RAILS_ENV=production bundle exec rails server -d

:-(

Ich pushe mal gegen Ende der Woche meine bisherige Arbeit an Docker-Containern \o/

Aber ich habe noch immer kein gescheites Setup gebaut, komme einfach nicht dazu. :-(

Ich pushe mal gegen Ende der Woche meine bisherige Arbeit an Docker-Containern \o/

FAV!

(we really need them in #pants :))

They’re so coming – I’m just taking things slow. :)

They’re so coming – I’m just taking things slow. :)

  1. could be worked around by adding an email add for gravatar, but the other arguments sound reasonable.

Just thought it might be an easy solution/workaround, as I don’t have an S3. :D

It’s not going to be terribly hard to fix; essentially, it’ll amount to serializing these images to the database1 you’re already using.

Just thought it might be an easy solution/workaround, as I don’t have an S3. :D

It’s not going to be terribly hard to fix; essentially, it’ll amount to serializing these images to the database1 you’re already using. I just need to make a decision if I want to apply the same to all future assets that #pants may be handling.

  1. If you’re concerned about performance, keep in mind that deserializing this stuff from the database will still be faster than pulling the original assets from S3. No matter what, the image that ends up being served needs to be cached on the HTTP level.

How about adding support for Gravatar for user images? As there probably already are ruby/rails gems for that, it shouldn’t be too complicated, right?

Wellllll…. #pants doesn’t have any email addresses.

Wellllll….

  1. #pants doesn’t have any email addresses.
  2. Even if it did, I’d hesitate to add Gravatar support for the simple reason that it would introduce a centralized component to a system that aims to be decentralized, so it’s sort of against the point.
  3. #pants is already better than Gravatar today, because if you know someone’s #pants user name (which is just their domain) – eg. hmans.io – you can always grab their user image by appending /user.jpg (eg. http://hmans.io/user.jpg).

The S3 dependency is mostly a technological issue that I will be able to solve on a code level; I just need to decide just how much handling of binary assets (eg. post images et al) I may want to allow in the future.

For those bold enough to try, I’ve put some preliminary #pants on Heroku install instructions up on the development wiki over at Github.

For those bold enough to try, I’ve put some preliminary #pants on Heroku install instructions up on the development wiki over at Github. Anyone willing to give it a go? Things aren’t as straight-forward as I’d like them to be in the long run, but they should work fine.

A couple of random thoughts related to this stuff:

  • When did web development become this complex? I miss the days of just asking people to throw a bunch of PHP files into a directory on their web space provider. At the same time, I don’t miss PHP itself, so don’t count on me writing a PHP version of #pants anytime soon.
  • Having Amazon S3 as a dependency just for being able to upload your user image feels a bit harsh. I’m already looking at alternatives (eg. putting uploaded user images into the database.)
  • Setting up #pants still is way, way too complicated. My current excuse is that I haven’t really invested a lot of time in making it easy so far, but I already know today that it will never be as simple as the “PHP way” described above. Either way, things will become easier over time.
  • My biggest hope in this regard is Docker, which I unfortunately have pretty much zero experience with. Any takers? The ideal scenario would revolve around someone (or myself) providing a set of Docker containers that you simply push to your favorite Docker-centric cloud host, but I really don’t know if those even exist (and if they do, how proven/stable/etc. they are.) Any pointers?

I never played Halo ever, being a PC guy and recently PS3 owner. So the combat in Destiny feels relatively fresh for me and i still find the Beta fun - considering we only have about four short missions and only one - very big -Zone. I am just realizing that i actually pre-ordered a game mainly because the controls are really nice.

OK -It is not just that: #Destiny is casual-friendly enough to just play one mission, then make lunch. I really like the RPG-Style character-progression. I think it is charming that absolutely every item has their own little description.

That said:

The evils of per-ordering deserve their own, especially long rant. As is said: I am weak and lazy.

I agree to the “just one mission” part, but I think they did mess up the character advancement in particular.

OK -It is not just that: #Destiny is casual-friendly enough to just play one mission, then make lunch. I really like the RPG-Style character-progression. I think it is charming that absolutely every item has their own little description.

I agree to the “just one mission” part, but I think they did mess up the character advancement in particular. I know the beta just gives me the first 8 levels of my character, but progression felt extremely linear, with loot really just reduced to large-font numbers which, too, felt like it was coming at exactly the right moment to make my character progress like everyone else. (I’m sure later levels will allow you to customize your character and their loot much more than is possible in the beta; I just don’t find it particularly interesting in the beta.)

All in all Destiny mostly makes me remember just how great a game Borderlands 2 is.

#WhatsNewInPants

#WhatsNewInPants

  • @mentions: You can now mention another user just like you know it from, cough, Twitter. Check it out: @hmans.io! Hooray! Note that this currently doesn’t do any checks if the referenced domain name is actually a #pants user, but your #pants will send the mentioned domain a Webmention ping (just like it will for any other link included in your post.)
  • Push tweaks: When you post something new, your #pants will no longer send pings to the users you’re following. This mostly means that for users that are not following you back, in order to push your post to their incoming timelines, you’ll need to @mention them like described above.
  • ATOM tweaks: Posts that are replies to other posts will now indicate this in your #pantsATOM feed.
  • Improved #IndieWeb standards support: the overall goal is to make #pants interoperate happily with non-#pants sites, so your #pants will now display incoming Webmentions from all sources (see http://hmans.io/oqq524 for an example of what this looks like.) Also, your posts are now fully marked up with h-entry microformats, allowing the #IndieWeb-enabled interwebs to fetch and process your posts in a structured fashion (example). If you’re interested in details on #IndieWeb, check out @indiewebcamp.com.

API Changes

In addition to all this, if you’ve been hacking around with the #pants API, please note the following changes:

  • The domain and slug fields have been removed from the post JSON data as they’re now pretty much obsolete. The post JSON still has url and guid, which should be enough to extract domain and path (slug) from.
  • The title, type and data attributes have been added to the post JSON data. I rambled about type and data for a bit yesterday; these fields don’t do much yet, but they’ll play a central role in a lot of things that are to come. title, of course, is the post title (which, as you know, is being auto-extracted from the post body.)

Enjoy!

Very much looking forward to the weekend, large parts of which I intend to invest into #pants development, focusing on cleanup and hardening.

Very much looking forward to the weekend, large parts of which I intend to invest into #pants development, focusing on cleanup and hardening. Why not Distributed Likes? I’ve actually fully implemented that feature, which is now living in a branch that I think I haven’t pushed to Github yet, but building it forced me to make so many minor and not so minor changes to the rest of the code base that I really want to backport most of that stuff first to give it some time to settle down before adding a big, new, user-visible feature (breathing out, right?)

Turns out the most straight-forward way of implementing distributed likes is making them just like posts; renderable, shareable objects living on their own URLs, moving across #pants nodes via webmentions, using pretty much exactly the same code that’s pushing and pulling posts between nodes right now. This is opening some interesting doors; since posts and likes (and soon reposts) are really just different object types living on the #pants social graph, why not open the whole thing up to pretty much any piece of data? Yeah, this is coming – in fact, it’s already supported in the current version with the new type and data post fields1. The rough idea here is that client apps (or #pants forks/reimplementations) can define their own post types, with posts carrying both structured data that can be read and processed by apps that understand the post type, as well as a body/body_html that can be directly rendered by clients that don’t.

But what does it all mean???!?! Well, essentially this means that #pants client apps (eg. third party stuff you buy/download in the app stores and connect to your own #pants site) can implement arbitrary features (photo sharing, event listings, todo management) without anyone having to add more code to the base platform app.

I’m probably easily excited, but I think this is pretty cool.

“NSA in da House” projected on the USA embassy in Berlin last night.

NSA in da House

#NSA #USA #Berlin

Can’t even begin to imagine all the watch lists we’re on now! \o/

Can’t even begin to imagine all the watch lists we’re on now! \o/