[HN Gopher] Saying Goodbye to Typo CI
       ___________________________________________________________________
        
       Saying Goodbye to Typo CI
        
       Author : robin_reala
       Score  : 93 points
       Date   : 2021-05-23 15:35 UTC (7 hours ago)
        
 (HTM) web link (mikerogers.io)
 (TXT) w3m dump (mikerogers.io)
        
       | maciejgryka wrote:
       | Sounds like a smart decision and, while it sucks to have things
       | not work out, I'm sure the author will do more cool stuff down
       | the line.
       | 
       | For everyone interested in "small SaaS" (for the lack of the
       | better term), I really recommend listening to the "Software
       | Social" podcast, co-hosted by Michelle Hansen, mentioned in the
       | article: https://mjwhansen.com/software-social-podcast/
        
         | [deleted]
        
         | rogem002 wrote:
         | I love the social software podcast! It feels like I'm listening
         | to real people building products, plus following along with
         | Colleen Schnettler build her product has been really
         | inspirational :D
        
         | mjwhansen wrote:
         | Thanks Maciej! :)
        
       | RodgerTheGreat wrote:
       | The conclusion is the key takeaway. If you're finding spelling
       | errors post-commit, it is too late to be directly actionable.
       | Automatically-generated pull requests are just layering on more
       | complications without addressing the core reality: If you can run
       | a linter locally, _before_ you commit, it is trivial to fix the
       | problems where they stand.
       | 
       | The same goes for many things that might be part of your CI
       | pipeline today.
        
         | bredren wrote:
         | This is something Pycharm catches as a warning in a manual
         | inspection or automatically prior to a commit.
         | 
         | And while nice, the inspections often catch other more
         | important code issues.
         | 
         | These are also generally highlighted with an indicator of some
         | sort to catch as you're working on the code.
         | 
         | Are pre-commit inspections / visual indicators not generally a
         | part of most dev workflows?
         | 
         | I would think spelling would be a part of the most basic text
         | editor / ide at this point.
        
           | Gibbon1 wrote:
           | As someone whose spelling is generally subpar having
           | continuous spelling checking in my editor is great.
           | 
           | Best would be if it's integrated with a Language Server
           | Protocol. For instance it would be nice to flag misspelled
           | variable, function, and class names. And only flag them where
           | they are defined. And not flag variable names in comments.
        
         | catillac wrote:
         | Yeah this seems like something better as a pre commit check, or
         | as a run on save, the same way I might run go lint or gofmt,
         | not after the code is in the repo but as I'm saving. The "not
         | talking to the users" mistake can be super fatal in products
         | like this.
        
         | epage wrote:
         | I'd phrase it slightly differently. We can and should fix
         | things in response to CI failures. The problem is more so the
         | cost/value trade off for developers. The lower the perceived
         | value is, the more good will that will be lost with developers
         | for having to do another iteration to fix them. Integrating
         | these into the developers workflow as early as possible, like
         | rustfmt or gofmt, lowers the cost and developers are less
         | likely to have a problem with it.
         | 
         | At this point, the main value of having something in CI is
         | either for the reviewers to give them a sense of things, like
         | coverage or to help enforce people are using those tools, which
         | means it should ail CI.
        
         | robertlagrant wrote:
         | I'd say the way to do it is to have a --check option which
         | fails if things are misspelled. That can be run in CI to catch
         | problems, and leaves the developer to fix it in their own way
         | (pre commit hook/IDE integration/command line tool/ability to
         | spell).
        
         | lol768 wrote:
         | I don't really follow this. Ideally, the spelling errors should
         | fail the build and ordinarily I wouldn't expect PRs to be able
         | to be merged with failing CI checks.
         | 
         | Presumably it's possible to suppress false positive typo
         | reports too and flesh out a per-project dictionary to help all
         | other developers?
        
       | vinceguidry wrote:
       | GitHub's ecosystem bears all the hallmarks of a platform that
       | management decided was going to compete with Amazon and Google in
       | just a few short years. Everything half baked and seems to exist
       | just for the pure purpose of being able to say it exists.
        
         | macintux wrote:
         | For me, it's been the enterprise security features that for the
         | most part aren't covered by the API, and have decidedly limited
         | docs. Very frustrating.
        
         | robertlagrant wrote:
         | It's got to - it's competing internally with Azure DevOps as
         | well.
        
       | bporourke wrote:
       | > I reached the 100 user threshold in about a month, then it took
       | GitHub over 6 months to allow me to start charging for usage.
       | 
       | That sort of delay can kill a new product's momentum. I wonder if
       | this is consistent with what others have seen or if it's
       | something unique to this project?
        
         | piotrkaminski wrote:
         | My 2 cents: I run Reviewable (https://reviewable.io), a
         | reasonably successful app for GitHub. It precedes Marketplace
         | so I handle billing directly with Stripe, but when Marketplace
         | recently reduced their fees to 5% I looked into migrating
         | there. The lack of developer control over subscriptions and the
         | painfully long turnaround times with support to get some
         | straightforward questions answered (3+ months!) convinced me
         | that they're not serious about it. Anecdotally, I also heard
         | that the discoverability boost from being listed on Marketplace
         | isn't that big either.
         | 
         | Based on my research I wouldn't recommend using GitHub
         | Marketplace in its current state.
        
         | evanelias wrote:
         | I had similarly negative experiences with the GitHub app
         | marketplace. They wouldn't even let me list my app as an
         | _unverified_ listing! That 's the lower tier which supposedly
         | had no minimum user count but didn't allow payments.
         | 
         | My app was nonsensically rejected for not having enough users
         | yet. Isn't the whole point of the marketplace to help obtain
         | users? When I replied to appeal (directly quoting the no-
         | minimum-user-count statement), I never received a response, and
         | none of the ~dozen GitHub employees I know were either willing
         | or able to help me.
         | 
         | I gave up on the marketplace and just wrote my own Stripe
         | billing, but after two years my app still only barely breaks
         | even on its infrastructure costs. I deeply regret wasting my
         | time building a GitHub app.
         | 
         | Adding insult to injury: my GitHub app is a SaaS CI version of
         | my open source CLI tool, which GitHub internally uses as a core
         | infrastructure component for their DB schema management. 8
         | months after my GitHub app's launch, GitHub open sourced some
         | Actions code which uses my open source CLI tool to
         | substantially duplicate the purpose of my SaaS app, albeit in a
         | less compelling way (their approach doesn't provide inline
         | annotations, is much slower to execute, and involves contorting
         | the CLI in unintended ways).
         | 
         | Now I keep getting support requests from random users who want
         | help configuring GitHub's action, but don't want to consider
         | ever paying for a simpler-to-install solution with more
         | features. It's extremely demotivating.
        
         | rogem002 wrote:
         | > I wonder if this is consistent with what others have seen or
         | if it's something unique to this project?
         | 
         | I've spoken to a few other GitHub app creators, it's a fairly
         | common experience. I think GitHub Actions are kind of viewed as
         | the preferred alternative by GitHub so that's what they're
         | focusing on.
        
       | robertlagrant wrote:
       | > I really feel that GitHub isn't interested in having 3rd Party
       | Apps promoted on their platform
       | 
       | I don't know if this is just a coincidence with Microsoft now
       | owning GitHub, but this has historically been a Microsoft trait.
       | So little third party software exists for Microsoft tooling
       | because there's the fear that as soon as they see it they'll just
       | do a first party version. (Recent example:
       | https://www.thurrott.com/windows/windows-10/235783/appget-cr...)
        
       | emptysea wrote:
       | One thing I miss when using VSCode is the lack of spell checking
       | compared to Sublime or even Vim.
       | 
       | I think a CLI might be nice, but even then typos in code aren't
       | such a big deal IMO. Sometimes they do come up with copy in UI
       | code, but even then, NBD.
       | 
       | So for me, a spell checker in CI sounds like a nice to have, not
       | a necessity.
        
         | epage wrote:
         | > even then typos in code aren't such a big deal
         | 
         | Maybe it was just me but at my last role, I worked on a piece
         | of software with a typo that stuck out like a sore thumb but
         | the cost was too high to ever fix it (impacted multiple
         | products with independent schedules or were just being milked
         | and had no staffing).
         | 
         | I also remember some bike shedding over a person using a
         | British spelling for a word instead of the American. Some times
         | linters are just nice for deciding minutia so people don't
         | argue (see also formatters).
         | 
         | However, I fully admit, compared to a lot of other priorities
         | in software, these are minor.
        
         | laumars wrote:
         | VSCode does have a spellchecker. I rely on it myself because my
         | spelling is abysmal (despite the lack of trying).
        
         | GordonS wrote:
         | I'm on mobile just now, so I can't give you the link or even
         | the name right now, but there is a good spell checker extension
         | available. I use it on Windows, but presume it works elsewhere
         | too. IIRC, it was a little fiddly to setup (think I had to
         | download spell check files separately), but it's been plain
         | sailing after that.
         | 
         | I mainly use JetBrains Rider though, and that has really good
         | spell checking support built-in. Something I really like about
         | Rider's support is that, just like lining rules, you have the
         | option of saving additional words at the "Team Shared" level,
         | so the whole team can use the same extra dictionary words. The
         | same function works in Visual Studio with ReSharper installed,
         | and presumably it's available in all JetBrains IntelliJ-based
         | IDEs.
        
         | tehalex wrote:
         | In VSCode, I use
         | https://marketplace.visualstudio.com/items?itemName=streetsi...
         | 
         | I also enable & use it with languages it doesn't really have
         | proper support for (like sql and ruby) - just add words to the
         | dictionary as they come up.
        
           | iudqnolq wrote:
           | The main annoyance is that the dictionary is directly inline
           | in your main json config file. It's around 50% of mine right
           | now. I wish there was a way to refer to an external file.
        
           | hebrox wrote:
           | I came here to recommend the same. This has saved me from
           | sooo many silly mistakes. English is not my first language,
           | or that of many of my colleagues, so it's very easy for
           | spelling mistakes to slip into the code. And very hard to
           | correct after it's part of the codebase...
        
       | mjwhansen wrote:
       | Mike, it took you a lot of courage to make this decision. You
       | deserve respect for making a hard decision and being public about
       | it for the benefit of others.
       | 
       | I'm so moved (and admittedly conflicted!) that my writing helped
       | you come to this decision. I'm grateful you were able to identify
       | the issue around permission, and also grieving with you about the
       | loss. (Closing down a business or project is a valid form of
       | grief. We don't often name it as such, but that sadness is real
       | and it is grief.)
       | 
       | It sounds like you learned a lot and will carry that with you to
       | your next projects. Wishing you all the best. I hope you stay in
       | touch and continue sharing what you learn from users, encouraging
       | and otherwise!
        
       | daxfohl wrote:
       | This seems like the challenge with things like github
       | marketplace. Devs rarely hold the purse strings. Managers can't
       | be bothered with the minutia. Indie devs that do care about such
       | things, well, already either spell well or have spell check in
       | their editors.
       | 
       | So there seems to be limited utility for github to even have a
       | marketplace. Enterprisey all in one solutions seem to be the only
       | thing that can succeed there.
        
       | epage wrote:
       | > Finally, I have been thinking about how to encourage spell
       | checking within code. I think a better solution would be a
       | terminal command (like Standard) where a user just can run:
       | 
       | Interesting timing since I've been polishing up my source code
       | spell checker in prep for announcing it. I even used the name
       | "typos" because I couldn't find it in use as a CLI.
       | 
       | https://github.com/crate-ci/typos
       | 
       | There are also some other code spell checkers out there:
       | https://github.com/crate-ci/typos/blob/master/docs/compariso...
        
       | felixfbecker wrote:
       | I'd love a GitHub Action that (unofficially) integrates Grammarly
       | with GitHub checks. Just like the unofficial VS Code extension:
       | https://github.com/znck/grammarly#grammarly
       | 
       | There is an unofficial SDK for TypeScript (maybe other languages
       | too) so this shouldn't even be too hard:
       | https://github.com/stewartmcgown/grammarly-api#unofficial-gr...
        
       | aledalgrande wrote:
       | Sad to hear it didn't work out, but I'm sure there were a few
       | lessons learned. Seems like the Github marketplace is not great
       | to launch and iterate fast. Maybe try the Slack marketplace for
       | the next micro product?
        
         | rogem002 wrote:
         | I'm thinking Heroku. The experiences I've heard from developers
         | writing for them has been super positive.
        
         | robertlagrant wrote:
         | Slack's is excellent, with its approval flow anyone can
         | initiate.
        
       ___________________________________________________________________
       (page generated 2021-05-23 23:01 UTC)