Hacker Newsnew | past | comments | ask | show | jobs | submit | secretsinger's commentslogin

Local-first architecture isn't just nicer for users: it also solves some of the pain-points of Flutter (and mobile/frontend dev in general).


Obligatory: Can you hook it up to GPT-3 and an email address, so a client can just email in a feature request and get it added automatically?


In South Africa, we have pretty harsh lockdown laws, including only being able to exercise within 5km of your house and only between 6am and 9am.

I'm a keen mountain biker, so I've put my energy and frustration into developing new mountain bike trails in the hills around my house. Been meaning to do this for a long time, but there are such good trails a few miles further away, so the incentive has not been very strong until now.

I'm building for about 1 hour per day on average, and I manage to get between 10 and 100m of trail built in that hour, so by the time the lock-down ends I'm aiming to have a contiguous piece of singletrack that's a mile long.

Also, I've been helping on a local project to develop an open-source ventilator (https://www.backabuddy.co.za/champion/project/rescuevent)

And I'm working on a peer-to-peer donation platform (which is not really ready to show to anyone yet)


Creating a new trail sounds interesting - I had to do similar as part of a service project when I was a kid, but I imagine it's much more fulfilling when it's for your personal use. How are you able to create the trail, is it free use public land, or more of a guerrilla repurposing of untended private land?


The land is in limbo: it's abandoned pine plantations currently being used by joggers, dogwalkers and (to a lesser degree) cyclists.

I can highly recommend trail building (both walking and cycling trails) as a combination of physical, aesthetic and intellectual challenges (figuring out how to use the terrain to be both fun and interesting/possible to ride and then moving tons of earth and vegetation to make it happen).


Paradyskloof?


My favorite project in this thread. Great work.


fellow saffer here, good for you!


ha, that's awesome! I started using this for my side project a couple of days ago (found you via google).

Great product, really useful.


Thanks, if you need anything ever or any feature requests just ping me at niftylettuce@gmail.com


If you feel like a wierdo while doing this, you can take some comfort in the fact that it is endorsed by one of the most reputable psychologists in the world (Seligman) and that is has been empirically validated as increasing happiness and reducing depression (https://www.ncbi.nlm.nih.gov/pubmed/16045394)

I agree it can feel like a strange thing to do, but in my personal experience the effects are amazing, not only on the person you write to, but also on yourself.


I can contribute some anecdata here. For about a decade now, I've made it a point to do some end-of-year giving to software projects I've found useful over the year, tracking down tipjars and paypal links and sometimes just emailing people to ask how I can say thanks.

I figure it this way: I'm using "free" software, but what if I wasn't? What would I spend on Windows licenses and apps and stuff over a year? I'll set aside that amount of money, and put it into the hands of those who deserve it.

In several cases, folks have asked me to give the cash to a charity instead, or find another project to support because they're doing alright and the words mean more than a few bucks.

Not only have I gotten some fantastically appreciative responses, but I also come away with a glowing pride and deep satisfaction myself.

Their commitment isn't thankless. My gratitude isn't silent. The feedback loop isn't broken, and the end-user's voice has been heard loud and clear.

It says "you're awesome".


Work: Our team has an extensive set of interlinked linked google docs for everything from how to set up your dev env to the plan for the week and logistics for off-sites. As well as a thorough README.md for every project we work on.

What makes the above work is a simple protocol: if someone teaches you how to do something, you're responsible for writing that something down. It's a simple honor system, but people tend to stick to it, and the result is an ever growing, live body of knowledge.

Life: Bullet Journal is pure magic, when I manage to stick to it :/


Our (fully remote) startup was acquired by a (fully non-remote) company about 18 months ago. My team was fortunate enough to be allowed to remain completely remote, although we have recently onboarded a couple of in-office team-mates. Most of us live/work a few hundred miles apart from each other.

Here are a few things that I miss in our remote team:

Face to face one-on-ones: I have weekly 1-1s with each team-mate. In previous on-site teams I found that fortnightly or even monthly was more than enough, but with the remote team I find that a weekly 30-60 minute catch-up is needed, because one loses a lot of nuance via even good remote tools. Is Bob feeling cranky today? On-site it was trivial to discern but remote is much harder. Then the 1-1s are less effective because one loses a bunch of the subtle organic cues that guide you in a normal 1-1 conversation.

Whiteboards: Sometimes we have long, complex conversations to resolve issues that a simple whiteboard diagram would resolve in 2 minutes. I know there are a bunch of tech tools that could alleviate this, but we don't have the budget for the really slick solutions and the less slick solutions are seriously lacking. We're considering buying a few ipad pros as an experiment - would be great to hear if anyone has had good results with these. I've not found a replacement for the humble whiteboard when it comes to hashing out a workflow or a layout.

Over-the-shoulder pair programming: I've not found a good solution to this. Screen sharing is abou half of the problem. Being able to point, grab the keyboard, etc. is the harder part to solve. VSCode live sharing is about the best option I've found, everything else has been close to useless.

Planning and retrospective meetings seem to take way longer and seem to be less effective than they are IRL. I think engagement is part of it (I'm a stickler for closing laptops/phones during meetings and that is obviously impossible during videoconference meetings). Another part of it is probably just the small size of faces on video calls. When you have 6 other people in a meeting, they each have less than a postcard of screen estate, so expressions are super hard to read, humour becomes harder, etc. Consequently it's super hard to keep meetings energised and on track.

Small acts of kindness: In our previous team, we would often make each other coffee or bring each other lunch. I found these little gestures go a long way towards easing the friction inherent in a team working hard together.

I'm not sure how many of these are caused/exacerbated by living in a country with crappy, unreliable internet. Maybe huge bandwidth would help?

Here are a few things that we found useful to help alleviate the above:

1. Regular in-person get-togethers: At least once per quarter, we have a 1-2 day session together, with lots of food, some beers. We spend a lot of time on high-level planning and introspection during these sessions, but also get together for detailed work sessions and pairing on hard problems.

2. Document the shit out of everything. Readmes, meeting notes, TIL slack channels, howtos and guides and playbooks for every possible activity. We have a rule that if someone teaches you something you have to document the lesson somewhere for the next person. Its baked into our team culture now and it helps us a lot, because you can't just grab someone to help you when you need it.

3. Zero tolerance for bad behaviour: Its a million times harder to fix conflicts remotely, so we have to be extra kind and respectful to each other

4. Shorter iterations: We run week sprints with documented goals and documented review/kaizen every week. It's a high overhead, but it helps keep everyone in sync, as well as highlighting problems quickly


> Over-the-shoulder pair programming: I've not found a good solution to this. Screen sharing is abou half of the problem. Being able to point, grab the keyboard, etc. is the harder part to solve. VSCode live sharing is about the best option I've found, everything else has been close to useless.

tmate is great for this so long as you're okay being 100% in-terminal. One person runs tmate which basically opens tmate and gives you an ssh url. Then everyone else just sshes in and is in the same tmate session - identical to if you both sshed into a shared host and entered a mutual tmate session. It has a hosted version but can also be self-hosted.


s/tmate/tmux in a few of those places

tmate.io


> Document the shit out of everything

Couldn't agree more. Someone in every meeting needs to be taking notes and sharing them to Slack.


When I was a kid, my father bribed and coerced me into playing with LOGO (really showing my age here). I ended up spending a fair amount of time playing with it, (I guess) learning a lot of basic programming concepts along the way. I have memories of my grade-school self struggling to grok recursion.

There were a few aspects of LOGO that made it nice to learn on: most notable was immediate visual feedback and the "telling the turtle what to do" approach to imperative thinking.

When my wife was pregnant, I was overcome with nostalgia about LOGO and hacked together an in-browser collaborative playground (http://turtology.herokuapp.com), which seems like a total dead end at this point. LOGO was genius in it's time, but it seems terribly dated now, even to my fanboy eyes.

Apart from Scratch (which has a bunch of mentions already), the nicest thing I've seen is Cubetto: https://www.primotoys.com The combination of rapid feedback, simple interface and a real-world "avatar" for your instructions seem to make it really easy to figure out, as well as engaging. Also, now that I have a toddler, I can also appreciate the genius of the simple, physical interface. My 2-year old is still a long way from reading or writing, but is quite capable of recognising that a symbol can represent an action or concept.

Now I just need to figure out how to get one shipped to me (not trivial if you live in Africa).


My mother introduced me to LOGO at age 8. She was a teacher but could barely program herself. Pretty soon I was teaching myself from books.


Most "non-tech" people have a reasonably small attack surface, so my approach has been to try and milk the Pareto principle:

Here are some things I've found which are simple enough to implement but actually offer substantial gains. Learned mainly from helping partners and parents:

1. Move them to Gmail. Email seems to still be the primary vector for most attacks and Gmail's filters are awesome.

2. Get them on a less permissive OS. Shifting from Windows to OSX/iOS has made a huge difference.

3. Teach them a reasonable password-generating method (correct-horse-battery-staple or some such). They are gonna forget and reset passwords regularly, which is OK. I gave up on getting them to habitually use a password manager.

4. Force (coerce/bribe/cajole) them to use 2FA on critical accounts (email, FB)

5. Tell them lots of anecdotes about hacks, things I spotted in my email, etc. As someone else pointed out, you can work in a lot of useful info in a memorable way in these anecdotes.

Tech does seem to be only part of the solution (and probably not even the major part). I've been doing some gig work for a company [http://www.popcorntraining.com] that does story-based security awareness videos, mainly for corporates. They have pretty good results based on fairly small time investment by the participants.

Sadly, most of the players in this market seem to be focused on big companies at the moment, with a few starting to aim at SMEs. We've bounced around the idea of trying to help the consumer market, but its not yet been worthwhile for them.


I remember Joel saying something about "smart AND gets things done" back in '06. But I guess the youth of today are too busy working 18/7 and learning the latest, hippest Javascript meta-framework to read such outdated doggerel. https://www.joelonsoftware.com/2006/10/25/the-guerrilla-guid...


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: