mhale

To have the best of all worlds:

- 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

This does not appear to be a total outage. I cannot reach any of our sites, and Pingdom also reports we are down, however, I can see normal looking traffic reaching our servers (via heroku logs --tail). In addition, members of our team are reporting via Slack that some can reach our Heroku-hosted sites, others cannot. It seems to be ISP-related. Two people within 1 block of each other on different ISPs see different results.

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.

Heroku apps are down, but API access is available.

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

It's not about tech point scoring, it's about quickly solving a problem. Specifically how can my customers on IPv6-only networks reach my service hosted on Heroku (which does not support IPv6)? Cloudflare is a practical and relatively easy solution to that problem.

I've also found this Geekflare tool to be useful to test the IPv6 compatibility of any domain/URL. https://gf.dev/ipv6-test

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/

The need for IPv6 support is real!

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.

I'm working on a project with some offline data synchronization needs, but haven't started implementation yet. I've been following CRDTs with interest. I also saw many of the same downsides mentioned in the OP, e.g. bloat (which apparently are being addressed remarkably well). Beyond OT, another approach I've run across that looks very promising is Differential Synchronization[1] by Neil Fraser. While it also relies on a centralized server, it allows for servers to be chained in such a way that seems to address many of the downsides of OT. I wonder why I rarely ever see Differential Synchronization mentioned here on HN? Is it due to lack of awareness or because of use-case fit issues or some fatal flaw I haven't seen? Or something else?

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

This is a good time to point out Micro.blog, an independent publishing platform designed to empower publishers and protect privacy. (Not my work, but I'm a fan)

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

Yeah, I struggle with this. Often when I see someone my brain doesn't present single name match, more often I have a list of potential matches in my head. e.g. "Scott or Rob" -- so I'm forced to just go with one, or avoid saying any name at all. I've gone for it and botched a name before and it was truly embarrassing. Often given a few seconds I can recall with certainty. It's the one-the-spot instant name recall that is difficult for me.

I'm pretty bad at remembering names, but my wife and I have worked out a system. If we're in a social setting together and I start to introduce her "have you met my wife..." she will jump in and introduce herself directly to the other person "hi, I'm Colleen...", which prompts the other person to directly introduce themselves to her (and thus taking me off the hook). As a result, if someone is introducing me to someone else, I tend to do the same thing -- hijack the introduction and introduce myself directly -- just in the case the person making the introduction needs an assist. Of course, if they've already greeted the other person by name, then no need.

I worked on a project that required some pretty standard line charts, but with the addition of an overlaid set of horizontal "benchmark" lines -- and some callouts. After struggling (and failing) to get what we wanted out of two different off-the-shelf graphing libraries (one of which was built on top of D3), we finally bit the bullet and just built the charts we wanted in D3 "from scratch". Once I wrapped my head around the model, it was such a pleasant experience. D3 is soooo nice and well thought out. You mayneed to level up in SVG, but it is so freeing to be able to bind data and display it basically any way you want. In hindsight, I wish we started with D3 from the beginning and I would not hesitate to pick it up for even simple charts again. It really is worth climbing the learning curve, which isn't as big and scary as it appears at first sight.

Sounds like an issue for the board of directors. Do you have a board of directors? If so, I suggest reaching out directly to board members one-on-one to raise these issues with them.

Ember is the PostgreSQL of JavaScript frameworks.

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

The wikipedia page on Subjective Logic goes into more detail: https://en.wikipedia.org/wiki/Subjective_logic

The most important agile practice, imho, is far and away the Retrospective. A good retrospective process will fix all other problems.

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!

Actually, this was the topic of my thesis for my Master's degree.

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

While you cannot ssh directly, you can get a bash shell on a heroku dyno quite easily by running:

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.

Thanks, and glad my comment helped.

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

Good luck!

In my opinion, the hardest question really is when should you throw in the towel?

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

Austin, Texas -- remote considered

Are you interested in helping families be healthier and happier?

You're in luck! SwimTopia is looking for Rails and front-end web developers.

SwimTopia provides web-based tools to help manage youth-sports teams and leagues. We provide content management, online registration, email, volunteer coordination, and more.

Our product is live with a rapidly growing base of happy, paying customers.

We are graduates of the Capital Factory 2011 accelerator program, and won the Demo Day pitch competition. Here's our pitch: http://www.youtube.com/watch?v=c0cNviPzjGQ

More info: http://jobs.swimtopia.com or email mason@swimtopia.com

FYI - the intarray contrib module for Postgres does support indexing of arrays of integers.

http://www.postgresql.org/docs/9.1/static/intarray.html#AEN1...

And it happens to use bloom filters under-the-hood to do it.

From the docs:

"Two GiST index operator classes are provided: gist__int_ops (used by default) is suitable for small- to medium-size data sets, while gist__intbig_ops uses a larger signature and is more suitable for indexing large data sets (i.e., columns containing a large number of distinct array values). The implementation uses an RD-tree data structure with built-in lossy compression."

That bit about the lossy compression in the implementation if referencing the use of a bloom filter. Also mentioned here, http://archives.postgresql.org/pgsql-hackers/2005-05/msg0147...

Using a custom index implementation that uses bloom filters internally is probably going to work out better in the long run. It should be way more efficient than storing the data in a bit field, using app-layer code to generate the bloom filter values, then doing bitwise comparisons on-the-fly at query time.

The Postgres query planner can also recheck constraints automatically to recover from bloom filter false positive matches at query time.

FYI -- bloom filters are already used internally within the PostgreSQL intarray contrib module and the full-text search functionality.

See: http://postgresql.1045698.n5.nabble.com/bloom-filter-indexes... http://code.google.com/p/postgres-learning/wiki/BloomFilter

EDIT: for clarity, typo correction