More from Marco.org
For the first half of my childhood in suburban Ohio, we lived next to Bob. Bob and his wife were a kind, reserved older couple who decorated their home mostly with crucifixes and talked about Jesus a lot. Bob helped my mom with a lot of common household tasks after my dad died. When she woke up to a small fire on our deck, she didn’t call the fire department — she called Bob.1 I never learned any of Bob’s political views, though I can make some guesses in retrospect. They never mattered. He was just our neighbor. We later moved, and hit the neighbor jackpot with Van. Van was deeply kind, generous, and friendly — the sort of neighbor everyone wishes for. In my lazy teenage years, he’d often mow our lawn or shovel our snow for us before I even woke up. As his mobility later declined, I was honored to return the favor. Van and his delightful wife passed away years ago, before I learned how either of them felt on any political issue. If they were my neighbors today, how likely would that be? * * * If I learn today that my neighbors have political views that my “side” considers unacceptable and unforgivable, should I be able to have dinner at their house, shovel their snow, or even greet them outside? Should I be condemned for supporting or associating with them in non-political contexts? Should I be condemned for not publicly condemning them myself? While privilege and power dynamics play a complex and unavoidable role in this, I don’t want to associate with any community that would insist on either of those.2 And I can’t help but feel that maybe we were better off before we knew everyone’s hot takes on everything. The town coffee shop was just a coffee shop. We weren’t publicly shamed for going there because one of the owners was an ass. It was just a place to hang out with our friends. Our casual work friends were just casual work friends. We didn’t expect them to take positions on the world’s most complicated conflicts. We could just talk about weather and TV shows, and maybe sometimes get a beer after work. And our neighbors were just our neighbors. That was the day I learned the word “SHIT!” ↩︎ Somewhere on Bob’s wall might’ve been a relevant statement from an influential political dissident about casting the first stone. ↩︎
I have ADHD. Probably.1 My entire adolescence was defined by forgetting to do my homework, disappointing everyone around me, and being told by every adult that I was lazy, “just” needed to try harder, and wasn’t living up to my potential. I’ll be working on the resulting shame and anxiety for the rest of my life.2 If someone tells me, “Remember to pick up the dry cleaning tomorrow,” I definitely won’t remember. If someone tells me, “Remember to put the laundry in the dryer in ten minutes,” I probably won’t even remember that. If you’re thinking, “It’s just ten minutes! Nobody can possibly forget that,” I have made an app that’s probably not for you. * * * Computers saved me. Despite constantly being told that I’d never get a good job, computers provided a lucrative career path filled with even worse academic performers who couldn’t care less about my grades. What a stroke of luck! I’d be mediocre to terrible at most jobs, but I turned out to be very good at using computers to turn coffee and Phish into money. But computers also save me in smaller, everyday ways. They help me remember. * * * Sorry, I just had to go put the laundry in the dryer, which I had forgotten. Really. It’s that bad. * * * Calendar alarms changed my life. Events without alarms don’t happen. (If you’re thinking, “Why doesn’t he just check his calendar?” I have made an app that’s probably not for you.) I had less success with reminders until we had ubiquitous voice capture. If I think of something at inconvenient times, like while driving or exercising, I need to capture it immediately or I’ll forget. It cannot wait until I get to my phone or computer. It has to be recorded right then or it’s gone. Siri, for all of its faults, has always been very good at creating tasks in Apple’s Reminders app — and Siri is everywhere. Computer. Phone. Car. Watch. I can almost always ask Siri to add something to Reminders. So Reminders’ integration and ubiquity are invaluable to me. The Reminders app, though, doesn’t fit me at all. I don’t like how it looks, how it works, or how it’s organized. Hell, I don’t even like its icon. There’s nothing about it I like. So I never open it. (Not as if I’d ever remember to check it anyway.)3 Most of my Reminders interaction has always been via Siri and notifications. And that fits me very well, with three major exceptions: If I say “Remind me to buy milk,” but I forget to specify a time (or Siri misses it), Reminders will never notify me, and I’ll never check the app, so it’ll be lost. If I inadvertently dismiss a Reminders notification without snoozing it, Reminders will never notify me about it again, so it’ll be lost. When I do snooze a Reminders notification, which I do a lot, the snooze options suck.4 This spring, I made myself an app to fix all three, and… it escalated. I’ve been using it for months, and it has profoundly improved my life. Today, I’m releasing it, in hopes that maybe it can help other people, too. * * * Introducing Unforgetful. The concept is simple: Reminders for ADHD. This means: It’s impossible to lose a task. Notifications always repeat, even if you miss or dismiss them, until the task is completed or deleted. Designed for procrastination. Snoozing is a core feature, with thoughtful intervals that scale as you snooze a task more. Nothing is hidden away. A hidden task is a forgotten task. No folders, no tags, no organization, no different views or modes. No judgment or shame. Nothing is overdue. You’re not in trouble. Everything is either due now or in the future. Didn’t get to it today? Maybe tomorrow. Every day is a fresh start. And Unforgetful does all of that with your Reminders data. That means: Siri works perfectly, everywhere. Just say “Remind me…” without having to specify an app. It replaces your Reminders notifications. Turn them off, turn these on. No import. This isn’t a new system to learn or migrate into. Your Reminders data is just… there. No export. If you try Unforgetful and it’s not for you, just delete it and turn Reminders notifications back on, and all of your data is right there in Reminders. Mix and match. Don’t like it everywhere? You can still use Reminders on your Vision Pro or whatever, or simultaneously use Unforgetful with Reminders or any other app that uses Reminders data. I’ve optimized lots of features and details for ADHD, too: Fast capture with dictation. Tap the microphone button in Unforgetful — or its full suite of widgets, or its Lock Screen or Control Center controls — and quickly dictate a task.5 Spaced-out notifications, not an overwhelming pile at once. If multiple tasks are set to alert you at the same time, they space themselves out so you’re not barraged with a hopeless stack of obligations. And the order changes every day, so nothing gets lost between things. Recurring-task backlogs don’t pile up. If you miss multiple intervals for a recurring task, completing it doesn’t make you click through all of your past failures to get to the present day… it just schedules the next one from now. Remind me 5 minutes after I get home. Location-based reminders can notify you after a set delay. Because if a “remind me when I get home” task fires as I pull into the driveway, I’ll forget it by the time I’m inside, unloaded, and ready to do anything about it. Unforgetful is a Mac and iOS app that’s $19.99 per year (US). One subscription buys all platforms. There’s a one-month free trial so you can really live with it and see if it’s right for you before paying. There are a million task-management apps. Unforgetful is not for everyone, but it’s really for me, far more than anything else has ever been. Frankly, I have no idea how to reach the other people it’s for. But I know you’re out there. If any of this resonates with you… give it a shot. Despite significant progress on my mental health around this from therapy and media, I haven’t (yet?) sought an official ADHD diagnosis because I haven’t sought medication, and that seemed like the main reason why I’d want a diagnosis. That’s probably worth reconsidering. I’ll make myself a reminder to do it. Someday. ↩︎ I saw a psychologist throughout high school for my homework problem. Rather than recognizing 7 of the 9 symptoms of what we now call “inattentive” ADHD, he was just one more adult condemning me for not caring. (I really did care. Nobody wanted me to be “better” more than me.) In the 1990s, if you didn’t do homework but weren’t hyperactive, you were obviously just choosing to be lazy, and the solution was apparently to apply more shame. Not all doctors are good. ↩︎ I’ve tried other apps that are beautiful and work differently, but they’re all complete task-management systems that introduce a lot of features and complexity that I neither need nor want, at the expense of Reminders’ ubiquitous integration that I highly value. I’ve also tried other apps that use the Reminders database, but I haven’t found any of them to be… good. (Sorry. I probably didn’t try yours.) ↩︎ At least they specify the actual snooze times now instead of vague descriptions like “the afternoon,” which I proudly take full credit for, since it happened to change only after I ranted about it relentlessly on our podcast for months. If I truly made this happen, it might be the greatest impact on the world I’ll ever have. ↩︎ Dictation just records every word you say as the title, which is extremely fast and reliable. It doesn’t yet recognize things like “Remind me to buy milk at 10 AM tomorrow.” I haven’t nailed that natural-language processing yet — coming soon, maybe! For now, Siri does that part better. ↩︎
As Apple celebrates its fiftieth birthday, we celebrate the spirit of its formation, when people who loved computers started making great computers to inspire more people to love computers. That spirit is difficult to find in the tech business today. Immense scale, soulless optimization, and an insatiable thirst for growth dominate its behavior and discourse, leaving little room for the spirit and principles embodied by Steve Jobs and Steve Wozniak. Apple still has this spirit, and I believe you do, too. But it’s not infinite or invincible. It’s under constant pressure, including from Apple itself. It seems likely that you’ll soon be leading Apple, which will place unfathomable responsibility on your shoulders. As you grow into the leader that we know you can be, I urge you, on behalf of everyone who loves computers as much as we do, to protect and cultivate this spirit of Apple’s founders as the company’s top priority: We love computers. We don’t hide that — we celebrate it! We use computers to enhance our minds, lives, and abilities — not to be controlled, restricted, tricked, placated, angered, or surveilled. Our computers work for us, with the utmost respect for our time, attention, money, data, and privacy. We are customers and owners — not resources to be harvested, annoyed, or badgered into ever more services and upsells. Apple leads the industry in these values, but leading doesn’t always mean excelling. Remaining true to these values requires constant diligence, honest evaluation, introspection, and the audacity and courage to effect change. Apple doesn’t settle for fine, functional, or good enough in its hardware (and thanks for your incredible work on that). We love making and using products that aren’t just great, but greater than they need to be, always raising the bar of greatness for its own sake. Software, services, revenue sources, and world impact need to be held to that same standard. Focus on making great computers with great user experiences above all else, and you can trust that every other major goal will follow: profit, market share, expansion, impact, and benefit to the world. Making great computers must remain Apple’s top responsibility, because if you don’t do it, nobody will.
Ten years ago, Apple’s Phil Schiller surprised Apple enthusiasts and developers by walking out on stage at John Gruber’s The Talk Show Live WWDC event and giving an open, human, honest interview to a somewhat jaded community. I wrote this in response: Both Apple and Phil Schiller himself took a huge risk in doing this. That they agreed at all is a noteworthy gift to this community of long-time enthusiasts, many of whom have felt under-appreciated as the company has grown. […] Phil’s appearance on the show was warm, genuine, informative, and entertaining. It was human. And humanizing the company and its decisions, especially to developers — remember, developer relations is all under Phil — might be worth the PR risk. This started a ten-year run of interviews by Apple executives on The Talk Show every year at WWDC that proved to be great, surprisingly safe PR for Apple. No executive ever said something they shouldn’t have (they’re pros), no sensational or negative news stories ever resulted from them, and Apple’s enthusiastic fans and developers felt seen, heard, and appreciated. * * * For unspecified reasons, Apple has declined to participate this year, ending what had become a beloved tradition in our community — and I can’t help but suspect that it won’t come back. (A lot has changed in the meantime.) Maybe Apple has good reasons. Maybe not. We’ll see what their WWDC PR strategy looks like in a couple of weeks. In the absence of any other information, it’s easy to assume that Apple no longer wants its executives to be interviewed in a human, unscripted, unedited context that may contain hard questions, and that Apple no longer feels it necessary to show their appreciation to our community and developers in this way. I hope that’s either not the case, or it doesn’t stay the case for long. This will be the first WWDC I’m not attending since 2009 (excluding the remote 2020 one, of course). Given my realizations about my relationship with Apple and how they view developers, I’ve decided that it’s best for me to take a break this year, gain some perspective, and decide what my future relationship should look like. Maybe Apple’s leaders are doing that, too.
Today, on the tenth anniversary of Overcast 1.0, I’m happy to launch a complete rewrite and redesign of most of the iOS app, built to carry Overcast into the next decade — and hopefully beyond. Like podcasts better than blog posts? Listen to ATP #596 for more! What’s new Much faster, more responsive, more reliable, and more accessible. Modern design, optimized for easily-reached controls on today’s phone sizes. Improvements throughout, such as undoing large seeks, new playlist-priority options, easier navigation, and more. What’s not Most features. Overcast is still Overcast! The audio engine. It’s the best part of Overcast, and still leads the industry in sound quality, silence skipping, and volume normalization. (More soon!) The business. I’m still a one-person operation, with no funding or external ownership, serving only my customers. My principles. I always want to make the best podcast app, and I’ll never disrespect your time, attention, or privacy. What’s gone Streaming. Most big podcasts now use dynamic ad insertion, which causes bugs and problems for streaming playback.1 Downloading episodes completely before they begin playback is much more reliable. Tapping a non-downloading episode will now open the playback screen, download it, then start playback. It works similarly to the way streaming did before, but playback begins after the download completes, not after a portion of it is buffered. On today’s fast networks, this usually only takes a few extra seconds. And in the near future, I’ll be adding smarter options and more control over selective downloading of episodes to further improve the experience for people who don’t automatically download every episode. What’s next The last few missing features from the old app, such as Shortcuts support, storage management, and OPML. These are absent now, but will return soon. More options for downloading and deleting episodes. Upgrading the Apple Watch app to the new, faster sync engine. (The Watch app is currently unchanged from the previous one.) And, of course, more features, including some of your most-requested features over the last decade. Getting this rewrite out the door was a monumental task. Thank you for your patience as I work through this list! Why? Most of Overcast’s core code was 10 years old, which made it cumbersome or impossible to easily move with the times, adopt new iOS functionality, or add new features, especially as one person. That’s why there haven’t been many new features or changes in years. You saw it, and I saw it. I wasn’t able to serve my customers as well as I wanted. For Overcast to have a future, it needed a modern foundation for its second decade. I’ve spent the past 18 months rebuilding most of the app with Swift, SwiftUI, Blackbird, and modern Swift concurrency. Now, development is rapidly accelerating. I’m more responsive, iterating more quickly, and ultimately making the app much better. Thank you all so much for the first decade of Overcast. Here’s to the next one. Dynamic ad insertion (DAI) splices ads into each download, and no two downloads are guaranteed to have the same number or duration of ads. So, for example, if the first half of an episode downloads, then the download fails, and it downloads the second half with another request, the combined audio may jump forward or back at the halfway mark, losing or repeating content. ↩︎
More in programming
My now-traditional “summary” of the conference along with my own commentary and thoughts.
Every year, browser vendors collaborate via the Interop project to synchronize their efforts on new HTML/CSS/JS features. This year, there’s a ton of super exciting features being considered! In this blog post, we’ll explore the CSS of the future, to get a glimpse of what we’ll soon be able to do.
Imprint’s average engineer is merging 4x more PRs than 2 years ago. Yay. Aggregated behind the average is something even more interesting: we have two teams that are merging 10x their PRs over that period. One engineer is merging 25x the PRs per week of our average engineer two years ago, and a number are merging 10x. That’s pretty neat, and the slope of the line suggests our average in a year is going to look much closer to today’s p90 than today’s p50. Even more importantly, we aren’t just shipping more, our quality has improved: incidents are down 42% half-over-half, and critical incidents are down 78% half-over-half. I think we’ve always known the quality/velocity tradeoff wasn’t a particularly useful construct, but that’s undeniable today. As we’ve walked this path, we–like everyone else progressing down it–have run into the problem of pull request review. The p50 pull request review took about 33 minutes to complete 2 years ago, but now takes us about 77 minutes. The slope here correlates tightly with the number of pull requests getting merged. Tightly enough that addressing it became one of my priorities for the week. We solved it! Just kidding, we’ve absolutely not solved it, but I think our current approach is an interesting one, which we call the small-change. The work discussed here was shaped and done by many folks at Imprint including Dan, Joy, Daniel, Lenny, Taylor, Ted, and Annie, among many others. Why review pull requests? There are four reasons we review pull requests: Knowledge sharing between author and reviewer – software engineering is generally learned via apprenticeship, and reviews are a primary mechanism of experienced engineers teaching others what good software looks like. We believe the current volume means that this knowledge sharing will have to move towards operating on clusters of pull requests, rather than individual pull requests Preventing errors – review has always been an expensive time to catch errors, and we believe that effective CICD along with harness verification techniques like poteto’s pstack are more effective mechanisms for preventing errors than review Preventing malicious behavior – my experience is that even careful code review will generally miss competent malicious behavior, although fortunately most malicious behavior is incompetent. We believe both sorts of behavior are best identified using a combination of fixed rules (modifying these specific objects/classes/files requires review), anti-abuse mechanisms that we’ve refined in our LLM-based member support experiences, auditing, and audit log inspection Compliance obligations in our documented controls – these can be changed, but today they require that an independent human reviews changes in a subset of our repositories In the modern development paradigm, we think there is a better solution for each of these problems. But, we also want to make these changes very cautiously. Small steps with small-change We believe we move fast by finding narrow, contained ways to validate new practices, so to iterate our way into an effective solution, we’ve developed the concept of a small-change. Here’s how it works: When a pull request is marked ready, CICD determines whether it is eligible to be a small-change. This is represented as a passing Github check. There is also a label for visibility, but it is the check itself, managed by the build and not human modifiable, that determines eligibility. (The label is used for initial filtering, but the check is still independently verified.) Something is a small-change if it meets all of these criteria: It is less than 1,000 lines of code There are no p1 or p2 findings from our ai-code-review automated review bot The author has “experience” in the service or application, defined as 10+ prior merged pull requests into that service or application’s directories. For changes working across multiple services or applications, the author must have experience in all of them to qualify Impacts fewer than N distinct services or applications. N is 1 on our frontend monorepo, and N is 3 in our backend monorepo, where typical changes will modify both a gRPC service and a common HTTP gateway Shared libraries and utilities files are not eligible for small-change Each repository has a .small_change file which allows per-path customization while we continue to tune the behaviors. For example, a service dealing with money movement can be excluded Our Slack automation tags every reference to a pull request with reacji labeling the state of that pull request, for example if it has failing tests, if it has been approved but tests are still running, or if it is ready to merge. We added a small-change reacji that indicates which of those pull requests meet the small-change criteria In our internal skills repository, we created two skills that have been distributed across harnesses: review-small-change which takes a list of repositories and reviews all open, non-draft, small-changes, including providing approval if they meet the review’s criteria (all checks pass including small-change check, and not touching on sensitive topics such as payments and security) review-pr-cluster which reviews batches of pull requests to identify common themes that came up, and suggest opportunities for discussion and adding verifications We set the social expectation that any error caused by a small-change is a failure in our system, and has to be solved at the system level: improvements to ai-code-review, to our verification mechanisms, to our CICD, to our harness, etc. This took about two days of infrequent attention to implement and rollout, although I imagine we will be tuning the knobs here for a long time. Maybe forever. fleet: centrally orchestrated harness I’ll briefly mention our other approach to reducing code review volume, which anchors on our centrally-orchestrated harness, fleet. (Which is similar to Stripe’s Minions although not following the one-shot approach in particular). We rely on fleet to implement and verify software in a highly controlled harness running in the cloud, with independent evaluation mechanisms to identify the correct number of independent reviewers for any given change. That number can be as low as one (e.g. fleet writes, one human reviews) for changes evaluated as safe. Results / next steps / reception I’ll be honest, it’s too early to give a useful result here. From early results, about 10% of changes qualify as a small-change. Those are now eligible for very fast approval, and generally get it unless they trip a flag, generally due to touching a security or money adjacent topic. While 10% is a small percentage, the core concept here is working, and ultimately will succeed or fail based on our ability to expand that percentage over the next few months in tandem with expanding our verification mechanisms to be increasingly comprehensive. This is ultimately going to fail or succeed depending on our ability to improve our verifications, which does require more difficult sorts of techniques to accomplish in low scale-complexity, high domain-complexity software than in the high scale-complexity, low domain-complexity products where many techniques like incremental rollouts are exceptionally effective. (Don’t get me wrong, they still work, they just provide less coverage when most users have different configuration and behavior.) Folks have not been uniformly excited about this, it’s a substantial change from how we’ve learned to be good engineers, and it’s uncomfortable to reevaluate whether a long-held best practice has become merely dogma. The most energizing part of the current cycle is that we get to reevaluate these practices we grew up on every week; the most painful part of the current cycle is that we’re likely to fall behind if we ever stop reevaluating them.
The park near my house has lots of chestnuts and my kids have been collecting them like crazy (it’s actually their favorite post-school activity). We accumulated quite a hoard. I thought it would be fun to make a launcher so we had something to do with our new chestnut collection. I wanted to go with a very simple crossbow-style design (like the famous D2 item) using latex tubing and a leather pouch for holding the chestnuts. This is what I came up with. It launches chestnuts about 220 feet, and it’s simple enough to build in an afternoon. The frame is a 42 inch 2x2 and a spare IKEA bed slat for the crossbeam, glued and screwed together. A 3/8 inch eye bolt goes through each end of the crossbeam, and the latex tubing is tied to those and to the pouch from a leather shepherd’s sling. Tying the tubing was the fiddliest part. It has to be stretched while you wrap it with butcher’s twine, so I clamped a couple of scrap blocks to my workbench to hold it. I like this design because the tubing can be wrapped around the eye bolts to easily add more tension and power. The Trigger My favorite part of the design was that I decided to use an archery release like this one for the trigger. It provides a safe and reliable way to hold the tubing back, and it’s made to let go cleanly. I 3D printed a little housing that mounts the release securely to the back of the stock, and the release clips onto a loop of archery D-loop cord on the back of the pouch. Then I added a dowel for a rear grip and an old handle I had previously removed from my shop vac. How Well Does It Work? We tried it at the park and it works surprisingly well. Aimed at about 35 to 40 degrees, it sends our chestnuts (on the small side, about 10 to 15 grams) about 220 feet. Thanks to the archery release, we haven’t had a single misfire. I got curious and did some rough math. To go that far with air drag, the chestnuts are leaving at somewhere around 85 to 100 mph, which works out to about the same energy as a paintball. So safety glasses are important and you never point it at anyone. You can find the 3D print on Printables and a full build guide on Instructables. Make sure to always use it with adult supervision :)
I have a lot of digital cross-stitch patterns and until recently they were a mess. My “collection” was a series of several hundred PDFs, disorganised and spread across my disk. Recently, I was looking for a pattern and it took me several minutes to find it. I had a brief moment of panic, thinking that I’d lost it, and the website this pattern came from is long since gone. Fortunately it did turn up, but it was clear I had to organise my pattern collection. Some people would use apps like Pattern Keeper or Flosshaven, but I just created another static website on my media drive. This is what it looks like: The patterns are arranged in a masonry layout with a preview thumbnail for each pattern, which is normally the first page of the PDF. If a pattern has multiple files – for example, different files for colour and black-and-white printing – there’s a list of links below the thumbnail. I can also add a source link to where I bought the pattern, if I want to find more patterns by the same author. Internally, it’s structured like my other static websites. The metadata for the patterns is stored in a JavaScript file, and then I have an HTML page which renders that metadata in this visual design. My pattern collection doesn’t change very often, so I’m adding new files by hand. There are no sorting or filtering options, because my collection is small enough that they’re unnecessary. I can scroll through the entire list in less than a minute and find whatever I need. I’d like to start making my own clothes soon, and I expect to copy this design to store clothing patterns. This collection now sits alongside my saved bookmarks, podcasts, TV shows, and more. I can keep all my patterns organised, and I won’t lose them in the depths of my hard drive. Technical tricks There are a couple of technical pieces I’m quite pleased with in this process: Masonry layout. I love the cascading grid style of a masonry layout, and I think they’re great when you have variable-sized content – like my pattern cards. I’ve been using them for over a decade; screenshots of my early web apps show my experiments with David Desandro’s Masonry.js library. Masonry layouts are now a native feature of CSS called “Grid Lanes”, which is simpler and more performant than the JavaScript approach. I’m excited to use these layouts in even more places. Thumbnails of PDFs. Most digital postage patterns are shipped as PDFs, and I’m creating the thumbnail images with my create_thumbnail tool. I had to extend my tool to support PDFs, which turned out to be straightforward with the pdf_oxide crate. I’d not come across Oxide before, but it’s a cross-language library for working with PDFs, and I can imagine using it in future. A coloured stripe for the palette. In the metadata for each project, I have the complete list of DMC thread colours and the pattern dimensions. I have a lookup table that converts DMC thread colours to hex codes, and then I’m able to create a linear gradient in CSS to render a coloured stripe of the pattern colours. Here’s an example from a pattern with four colours: border-bottom: 12px solid transparent; border-image: linear-gradient( to right, #7a451f 0%, #7a451f 25%, #985e33 25%, #985e33 50%, #e4bb8e 50%, #e4bb8e 75%, #361f0e 75%, #361f0e 100% ) 1; Building the HTML, CSS, and JavaScript was very quick – I have notes on how I build my media sites, and I’ve done it plenty of times before. I threw together the initial prototype in less than 15 minutes. The longer part was finding all the PDFs scattered across my disk – but now that’s done, and I know exactly where to find my patterns. [If the formatting of this post looks odd in your feed reader, visit the original article]