siralonso

If any of this looks like fun (it is so very much fun), dropping by your friendly local soaring club on a weekend is a good place to start! The Soaring Society of America has a club map here: https://www.ssa.org/where-to-fly-map-2/

Super affordable for an aviation thing. I'll often fly 4-5 hours from a $50 tow. My previous club charged about $500/yr with no hourly fees for glider use. I bought my own mid-performance glider for $15k and a $200 annual inspection. Occasionally you do land out in a field and need to buy dinner for the club-members that come pick you up!

Also, as pointed out below, Github's GraphQL types also include fields like `permalink` and `url` (and interfaces like `UniformResourceLocatable`) that probably save you from needing to construct it yourself.

I wouldn't decode them like this, it's fragile, and global node IDs are supposed to be opaque in GraphQL.

I see that GitHub exposes a `databaseId` field on many of their types (like PullRequest) - is that what you're looking for? [1]

Most GraphQL APIs that serve objects that implement the Node interface just base-64-encode the type name and the database ID, but I definitely wouldn't rely on that always being the case. You can read more about global IDs in GraphQL in the spec in [2].

[1] https://docs.github.com/en/graphql/reference/objects#pullreq... [2] https://graphql.org/learn/global-object-identification/

Ditto, except in my glider! I would appreciate a slightly smaller form factor, though - the cockpit in the Libelle is a bit... tight.

There are plenty of different definitions of the word "bubble" out there, but most of them relate in some way to asset prices coming untethered from fundamentals. For example, here's Schiller's from 2015:

> A situation in which news of price increases spurs investor enthusiasm, which spreads by psychological contagion from person to person, in the process amplifying stories that might justify the price increases and bringing in a larger and larger class of investors, who, despite doubts about the real value of an investment, are drawn to it partly through envy of others’ successes and partly through a gambler’s excitement.

You can find more academic definitions, but this one seems pretty spot-on when you hold it up next to the famous manias throughout history. Price increases drive further price increases, because the draw of future price increases is strong and the concept of "overpaying" for an asset ceases to exist.

The author, on the other hand, attempts to define a bubble as:

> ... an objectively irrational shared belief in a better potential future

While it's true that innovation/invention (and sure yes marriage too!) do require optimism and some degree of irrationality, it's a far cry from the "animal spirits" that cause investors to abandon any notion of a fair price in favor of momentum.

Sure, in some way bubble-era investors "believe in a better potential future", but it usually seems to be a future of further price increases, and any narrative required to support those prices becomes thinner as the price rises. This can be a lot of fun! However, it is neither sustainable nor a clear net positive.

One of the reasons that (certain!) bubbles are so damaging is that the least sophisticated investors with the most to lose get pulled in last. A series of investors are holding the assets through the entire post-bubble price decline - someone "cashing out" at the peak means that someone else is "buying in". It's a little uncomfortable to claim the following benefit to the 2008 financial crisis:

> It created more housing inventory, and since the new houses were quite standardized, that made it great training data for “iBuying” algorithms

On the other hand, some bubbles do create useful infrastructure - the Dotcom bubble laid a lot of fiber (mentioned in the article), and the railway mania of the 1840s laid a lot of track - although the latter was pretty "inefficient" due to high construction costs, parallel routes, and etc.

I'm not really sure what the author is trying to justify here. Bubbles are what they are, we basically know how they work, and we appear to be living in one today! They'd probably be getting a lot less push-back if they avoided trying to re-define the word "bubble".

Yep, I was wondering the same - it reminds me a lot of the SwiftUI visual editor in Xcode. Very nicely done.

I've been consulting full-time since my early 20s - it's been an adventure!

You could talk to your current employer about switching to a part-time contract - it seems like in the last couple of years, more companies (especially startups) are comfortable with this + remote. If you can get them at 20/wk, that will give you some good security while you work to fill the other 20 (sounds like you may already have a jump on that).

Have a lot of meetings with friends and past coworkers, and let them know you're striking out on your own with a particular skillset. All of my best projects have come from connections, and my worst ones have been anonymous inbounds/etc. If you're in-demand, you should be able to line something up before reducing your FTE hours or quitting your job. It might take some time to find a good set of clients + rhythm, and you want to avoid "burning savings" during that period as much as possible.

Do good work. It's good for your clients, good for referrals, and good for your soul. You're a craftsman, and your name is attached to your work in a new way as a consultant.

I charge a reasonably high hourly rate for my work, and my clients are usually around 15-20 hours a week. I've found two clients to be the right number for me. For them, it's a way to get senior experience on the team for the yearly price of a more junior dev, and for me it's a way to make a good salary, while getting to work with startups and enjoying some freedom and flexibility to do the things I love (traveling and learning to fly!).

I try to keep a bit of "slush time" (like 5 hrs/wk or so) to work on interesting one-off client projects that come along. They're fun and stimulating, and they keep me sharp at selling my skills to completely fresh clients. I normally work on the frontend/backend, so getting to work with things like Swift or ARKit is great. These projects are also really low-pressure, because my main stream of income comes from steady long-term engagements. This is my "blogging".

I jumped in feet-first, but I was a broke college student (and self-taught developer) when I started so my burn rate was ridiculously low. It took me a long time to find a good pace and to build a good network, and I started a few companies along the way. I'd only recommend doing it this way if you're young and resilient - in retrospect, I could have been doing many of the things I needed to do (getting experience, finding clients, making friends) with a more stable salary. I don't know if I would have, though - so the pressure was helpful in some ways. I was also lucky to be in a stage of life where stability was less important than adventure.

Hope some of that is useful, and best of luck striking out on your own!

These two things are simultaneously true:

1. The experience of using a native app is substantially superior to web/electron. 2. Figma has done an amazing job of building features to support teams and organizations.

I used to use Sketch, and now I use Figma. Do I wish Figma had a native macOS app? Absolutely. Would it be better than the web/electron app? Definitely.

Native vs web isn't a feature differentiation - it's a matter of user experience (responsiveness), platform integration (filesystem, native controls, accessibility, iCloud), and delivery (App Store vs download). As a company, the choice boils down to: "Are you going to spend more resources supporting multiple platforms but delivering the best possible experience? Or are you going to spend fewer resources to ship an inferior experience faster?".

I do enjoy Figma, but it's worth calling out that they're compromising on user experience by going the Electron route. Yes, I know that maintaining a Swift version of Figma alongside the web version would be tough, but they're not an under-resourced team and I believe they could make it happen.

Thanks! METARs [1] are standardized weather reports that pilots use to evaluate current conditions. They're often reported from stations located at airports, and include (among other things) wind direction, cloud bases, temperature/dewpoint, current altimeter setting, etc. They look like this in raw text form:

KMDS 150935Z AUTO 30009KT 10SM CLR M02/M06 A3007 RMK AO2

This app parses METARs into a visual representation, and displays it in a widget on your home screen. Useful for keeping tabs on current conditions!

[1] https://en.wikipedia.org/wiki/METAR

Good callout. I've got a feature coming to show age on the widget face, but for now you can tap the widget to view the full version, which includes the age and timestamp.

Not a pain at all - I did explore this, but I wasn't really happy with the result - which may have been because I was trying to cram it in with the existing information. Having an alternative layout that is more cloud-centric instead of wind-centric might be the ticket. I'll see what I can do. Thanks!

Thanks! Onwards to the instrument rating.

That's a great idea RE: nearest reporting airport - I've put it on the list to explore for the next version.

Haha, roger wilco on the taildragger time.

Me too! The lack of ForeFlight widgets was the reason I started hacking on this, actually.

Love the idea of showing wind direction relative to the phone - one challenge with this is that you're not allowed to do any animation in widgets (for power reasons, I assume?). Hopefully they'll open this up a bit more in the future.

+1 on a runway visualization - it would be really useful to see the crosswind component (life or death for my tailwheel training, haha). Ditto for TAFs and surface analysis.

Thanks for the feedback and feature suggestions!

Hi all! This was a side project I worked on over the last few months while learning to fly in South Dakota. I learned a lot about working with Widgets and SwiftUI, and I hope to do a writeup on those soon. Feel free to ask me anything, and if you're a pilot I hope you take it for a spin!

Lots of negativity here, but I think if your goal is to be able to sprinkle in bits of interactivity (or demos) among mostly static content, this is a great choice. Yes, it has more dependencies than some other solutions - but the goal isn’t to be zero-dependency - it’s to remove as much friction from your publishing process as possible while still providing the required capability.

If you want to intermix markdown and react, check out MDX. You can write a file that’s 99% vanilla markdown, and just drop in a react component at the appropriate point.

I’ve been using the muji cases for years. My partner just got an Away case of equivalent size as a gift, and I can’t figure out why people would choose them over muji. In almost every way the muji cases feel better to use, and they seem much more durable.

The one attractive thing about the away cases is the lifetime warranty, but I don’t know how easy it is to submit a claim.

I've been traveling full-time for a year and living out of basically one big rolling-suitcase. Every time I'm back in the states, I convince myself to put the OP-1 in storage - it's just taking up weight, I could just as well use Ableton, etc...

...but I can never bring myself to leave it. I don't use it a ton, but when I do I get sucked into it for 4+ hours. I especially love to use it on long international flights (I read someplace this was one of the design goals), and my tape tracks are crammed with loops from the last 5 years - it's unexpectedly nostalgic to listen back.

I originally bought it because of that strange impulse you mentioned, at a time when I really shouldn't have been buying expensive synth-toys - but I'm so, so glad that I did. Totally encourage you to pick one up if you ever get the opportunity!

One datapoint to the contrary - I had an excellent experience with their support. Shortly after I bought my original OP-1 (the $800 version), I managed to brick it during a firmware update (my computer died while loading the new FW IIRC). They're a Swedish company but had an "authorized repair" guy based in the states, so I just dropped it in the mail and had it back in about a week.

Can't remember if they covered shipping, but they were super communicative through the whole process.

This was a few years ago, so maybe that's changed!

IIRC, the instability is caused by the engine nacelles (the metal shroud around the turbofan), and therefore is present whether the engines are active or not.

I studied in Boston and then lived in SF for several years, and also needed a break.

SF is incredibly beautiful - land's end, the presidio, twin peaks, the fog, hwy1 in either direction - but I started to feel like the natural beauty was one of the only positive (non-professional) bits of living there.

Anyways, after a bit of travel, I'm considering Boston again for grad school. It's a really awesome city - super diverse, and the winters aren't as bad as everyone says they are. Enjoy!

Our last app (Chorus, a podcast player mashed up with a social network, http://chorus.am) was built entirely in react-native - with the exception of the streaming implementation. In my mind, it's a great example of the optionality that RN gives you: easy cross-platform UI dev with an escape hatch to write native code when you need to.

The "telegraphing" of moves in ITB is really great. The devs worked on FTL previously (also a great game if you haven't played it!), and one of the really nice interface choices they made is to make the effect/requirements/stats/etc of every item/weapon/crewmember visible when you hover your mouse. You can tell that they care about giving the player all of the information they need to make a decision.

You might like this article on RockPaperShotgun that does a bit more of a deep dive on the interface design challenges during ITB: https://www.rockpapershotgun.com/2018/03/05/into-the-breach-...