- your own blog on a domain you control

- effortless crossposting to bluesky, mastodon, threads, linkedin, and others

Then micro.blog is a great solution!

It follows the POSSE principle: Publish on your Own Site, Syndicate Elsewhere.

see: https://micro.blog/about/crosspost

We proxy some services through Cloudflare to gain IPv6 support, and all of those are down, which suggests the Cloudflare -> Heroku network route is broken.

Might be a good time to run: heroku pg:backups:download

Geekflare (https://gf.dev/) has several other useful tools, worth checking out.

This page is useful to test the IPv6 compatibility of your current network/browser: https://test-ipv6.com/

This site: https://whynoipv6.com/country/us -- provides a "wall of shame" summary of sites that do not yet fully support IPv6, in order of Alexa rank. It is definitely surprising, even shameful, that so many top sites make this list.

That Twitter and Amazon don't have full IPv6 support yet blows my mind.

It's also worth noting that IPv6 networks definitely DO exist in the real world.

My tiny startup provides software to run sports teams (mostly swim teams) and we've run into several cases where new wifi gets installed at a neighborhood pool, and the network is IPv6 only. So far, the pattern seems to be cases where AT&T is the ISP in the Houston area. To troubleshoot these issues via phone support, we ask if the customer can reach amazon.com or twitter.com. If not, it's a pretty good sign they are on a IPv6 only network.

Apple also requires IPv6 support for backend services for approval of iOS apps in the App Store (although, in practice, this requirement is not consistently checked). See: https://developer.apple.com/support/ipv6/

Fortunately, adding IPv6 support to a site is relatively simple using Cloudflare. See: https://www.cloudflare.com/ipv6/

[Edit] To clarify, I'm not affiliated with the Why No IPv6? site. I just found it to be a useful resource. The site credits https://crawler.ninja/ as the source of its data.

[Edit 2] Added link to Apple's IPv6-only support policy.

[1] https://www.youtube.com/watch?v=S2Hp_1jqpY8

Check it out: https://micro.blog/

Similar to the way Postgres has deep roots that trace back to Ingres[1] in the days before SQL was a solidly established standard, Ember traces it roots back to SproutCore[2] in the JS framework pre-historic era of 2010.

And the same way PostgreSQL was seen as a second-tier or only "historically significant" open source database, the PostgreSQL team just kept at it, toiling away year after year, steading churning out awesome code and excellent documentation, getting better and better with each release. Like clockwork.

In the same way PostgreSQL is now, finally, enjoying more popularity and getting the recognition (long overdue in my opinion) for the awesome platform that it is, I expect that in time more developers will come around to appreciating Ember. The Ember leadership is definitely approaching the project and the processes around it like they intend to be not just relevant but pushing the boundaries for a long time to come.

For one example this boundary pushing, you should not miss @tomdale's talk at ReactConf about GlimmerJS (the view layer extracted from EmberJS). It is, in my humble opinion, simultaneously mind-blowing and and inspiring.[3]

[1] https://www.postgresql.org/about/history/ [2] http://yehudakatz.com/2011/12/12/amber-js-formerly-sproutcor... [3] https://www.youtube.com/watch?v=nXCSloXZ-wc

In the post, you sort of dismiss it out of hand because it is supposed to be a discussion limited to scrum, but that is an arbitrary and self-imposed restriction. You are doing it wrong. Remove that restriction and the doors will open up.

The retrospective is about creating time for the team to review what works and what doesn't about the software development process in general (no need to limit to scrum).

I've seen retrospective discussions veer into company culture, the need for faster hardware, testing processes, etc. Anything related to making the software, the software development process, or the team better should be on the table.

A good retrospective enables the team to use its sprints as experiments to try different things, to evolve the practices to better fit the needs of the team and organization. If stand-ups aren't working, go a sprint without them, or doing them differently -- whatever change would address the weakness identified by the team -- then in the next retrospective reflect on whether it actually improved things. Rinse and repeat. Done properly, a good retrospective will enable your team to evolve and get better and better with every sprint.

Points can be frustratingly fuzzy, but they serve a valuable purpose. They give a measure of team productivity (e.g. velocity), even if imperfect. Yes points can be gamed, but a team should learn quickly that gaming only serves to fool themselves. Because of they can be gamed, I'm not a fan of using points as an externally visible "vanity metric". They should only be used or shared within the team. They should not show up in performance reviews or presentations to management. But points can be very useful as an internal metric for the team to measure whether or not tweaks to the process made a positive impact. You need some way to objectively measure the success or failure of your process experiments.

Of course, any metrics used are themselves certainly deserving of scrutiny and fine-tuning, as poor metrics lead to poor decisions. To me the benefit of points (or t-shirt size estimates) over something like hours is that in software development, hour-precision estimates give a false sense of accuracy. It requires more effort to provide more precise estimates, yet they won't be any more accurate (given the inherent non-repetitive nature of software development). Thus, the use of a coarse-grained measure like points serves to re-enforce the notion that the estimate are inherently imprecise and that we don't want to waste effort on greater precision estimates.

All that said, whether or not to use points or any measure of team productivity at all is a team decision. If the measure isn't serving the goal of improving the software and the software dev process, then change it or get rid of it. That's the beauty of the retrospective -- it explicitly encourages this sort of process-hacking and fine-tuning.

Embrace the Retrospective!

Link: http://flowdelic.com/2005/03/03/learning-from-open-source/

Abstract:

In this paper, I study the workings of several successful Internet-based collaborative communities to identify what it is that enables them to succeed, even thrive, despite the highly-dispersed nature of their collaboration. This research reveals that while the practices and tools used by the referenced communities are important to their success, the most critical difference lies much deeper, in the economic-basis of their organizational structure. This economic mode of production, described by Yochai Benkler as “commons-based peer-production”, is studied to answer two key questions: First, does this economic model, in itself, encourage more successful virtual teamwork? Second, is the peer-production model of collaboration fundamentally tied to the open source model or can it also be applied in a commercial context to create proprietary products?

A key source for the paper was "Coase's Penguin, or Linux and the Nature of the Firm" by Yochai Benkler.

Link: http://www.benkler.org/CoasesPenguin.html

In this paper Benkler describes a mathematical model for human motivation, which accounts for influence of money. Highly recommended read.

Edit: fixed name typo

heroku run bash

This can be very handy for debugging.

That said, heroku will spin up a new dyno instance to run the bash shell. You cannot (as far as I know) get a shell on a specific dyno of your choice.

Startups are REALLY FREAKING HARD, but you are not alone. ;-)

Good luck!

There certainly are a lot of zombie companies out there with founders toiling away on "bad" ideas with seemingly no hope of success, burning precious opportunity cost with each passing week, month and year.

At the same time, one hears again and again that the successful founders are the ones who don't give up. That success comes from facing down those doubts, shaking the despair and finding a way to keep going even when it feels everyone around you thinks you are going to fail.

I don't have an answer other than to say that for anyone it is a very personal, gut-wrenching decision. If it is no longer worth it to you, then that is your call and I don't think anyone else -- especially someone who hasn't entered the same arena -- should think any less of you for it. Most startups fail after all.

And, I think that is likely close to the answer to the question. The right time to quit is when you no longer believe in the idea, or in your ability it make it succeed, or even that the idea is superior to other opportunities which might be available to you.

I'm not speaking as someone who has had huge success, but as someone who has faced setbacks and doubts, has come close to running out of money multiple times, but has somehow managed to get past those challenges and has become a bit more comfortable riding this crazy roller coaster.

What I've found is that the drive to "find a way", that survival instinct to keep going because you believe at your core in what you are doing -- that triggers creative thinking. And when you open your eyes and look around you see there are resources and people willing to help you that you didn't see before. You see new paths that were not visible before. At least that's been the case every time in my experience. Once you get past the doubt and are determined to find a way, then you find it. I suppose, until the last time, when you don't...

Ben Horowitz described it as "focusing on the road, not on the wall"[1] and that rings very true to me. You can only see the opportunities around you when are able to stop focusing on the wall (impending doom).

I don't believe founders should be guilted into chasing ideas they no longer themselves believe in. There are certainly cases where quitting is going to be the right call.

But human psychology is such that you will want to "flee the danger" and you will see certain doom when there may very well be a way out.

My two cents (if it is worth even that) is to never decide to quit out of fear.

Don't quit because you doubt your chances.

The time to quit is when you no longer believe that what you are working on is what you really should be working on.

[1] What’s The Most Difficult CEO Skill? Managing Your Own Psychology -- http://www.bhorowitz.com/what_s_the_most_difficult_ceo_skill...

EDIT: fixed typo

Comments URL: https://news.ycombinator.com/item?id=8048807

Points: 6

# Comments: 1