Sunday
Jun252023

benji.io โ€” new site

Wow, this site is old!

Go to benji.io for fresh bits!

Friday
Sep152017

VSCode performance fix for Mac OS X Sierra

I recently started using VSCode for my Ember development, and I like a lot about it... except, it was slow! I'd been using JetBrains IDEs for years, first RubyMine and then WebStorm, and I wanted to try something new & shiny. (I like shiny things.) 

When I ran Ember, Chrome, and VSCode together, horrible things happened. My CPU spiked and my computer crawled. From experience with Sublime and WebStorm, I suspected it was watching too many files. I found a setting that should have helped, but didn't help enough, and then _another setting that fixed the problem entirely_! 

The new special setting is `files.watcherExclude`. Apparently just `files.exclude` isn't a strong enough signal that VSCode should _really, truly_ ignore those files. 

```
  "files.watcherExclude": {
        "**/.git/objects/**": true,
        "**/.git/subtree-cache/**": true,
        "**/node_modules/*/**": true,
        "**/dist/**": true,
        "**/tmp/**": true
      },
  "files.exclude": {
        "**/.git/objects/**": true,
        "**/.git/subtree-cache/**": true,
        "**/node_modules/*/**": true,
        "**/dist/**": true,
        "**/tmp/**": true
      },
``` 
All of the IDEs I've used have required some tuning of this sort. With the JetBrains IDEs, we just have to configure the JVM properties, and the internet knows that pretty well... but I haven't found this fix for vscode mentioned anywhere yet. I hope it helps. 

 

Tuesday
Feb022016

Resources for Beginning Japanese

I have started learning Japanese! Partly to prepare for a trip in October, but also because I want to stretch my brain in different ways. It turns out that I really enjoy it. 

I'm taking a face-to-face class at the Japan Society of California, but that's mostly just to get some experience with actual conversation with a native speaker. I'm actually mostly crafting my education myself. So, without further ado, here are some of my favorite resources:

 

  • Start with learning hiragana. The Tofugu Guide to Learning Hiragana is the best out there. 
  • RealKana is a good app and website for drilling hiragana and katakana. Unlike many other tools, it shows the characters in multiple fonts, and lets you choose which characters to drill. 
  • I use the Genki textbook as my main text. The class I'm taking uses Japanese for Busy People; I like its focus on business people rather than college students, but the explanations are better in Genki. 
  • WaniKani is a fantastic spaced-repetiton system for learning kanji and some vocabulary. It has a whole coherent system of mnemonics that are hilarious and fun. 
  • Fluent Forever is a book with a general approach to learning languages. The author suggests that I will get much more out of a deck that I build; so far I have found that to be true.  
  • Anki! Anki is a general spaced-repetition system -- aka flashcards, but better. There are many, many decks to download, but the act of making my own cards seems to help with retention. 
  • Pimsleur Japanese.  These audio lessons focus on conversation and seem to be obsessed with drinking alcohol. "Now ask the woman if she'd like to have a drink with you. Suggest that you meet at the hotel, or at Miss Suzuki's place." The rest of my materials don't ever prompt me to produce speech, and in the end I want to be able to talk to people, so this is a great resource. 
  • JapanesePod101.com. This is fun supplement to everything else, good for conversation and culture, but not enough to actually learn Japanese. The dialog is almost all with native speakers, and it features an american guy who lives in Japan and talks about his experiences there. 

And then, I've tried out a few resources and decided they're not for me:

 

  • Rosetta Stone. I get access to this for free because I'm a Brown University alum -- nice perk. The problem is that Rosetta Stone is so focused on audio and way too devoted to their own method. It doesn't mix well with other resources. Once I'm in a lesson, it's very hard to skip forward. I'm usually frustrated with the pace when I'm in Rosetta Stone. 
  • Rocket Japanese. My main problem with this is that half of the dialog is by the founder, who is a non-native speaker. Bah, I don't want to spend my time listening to an Englishman speak japanese.

More to come as I discover more great stuff. What do you like? What have I missed? 

 

 

Friday
Oct022015

"Could not find watchman" doesn't actually mean it can't find watchman!

I've been doing an ember-cli upgrade, and I started seeing this error message when I start the server:

$ ember serve
Could not find watchman, falling back to NodeWatcher for file system events.
Visit http://www.ember-cli.com/user-guide/#watchman for more info.

This was frustrating because I knew I had watchman installed just fine!

$ which watchman
/usr/local/bin/watchman

This issue on the watchman repo was helpful in figuring this out. Running watchman watch . gave a much more interesting error message:

$ watchman watch .
/Users/benji/Library/LaunchAgents/com.github.facebook.watchman.plist: Operation already in progress ^C ```

The solution for me was to tell launchtl to forget about watchman:

$ launchctl unload ~/Library/LaunchAgents/com.github.facebook.watchman.plist 

After that, ember-cli ran watchman just fine.

There's an issue for this; I'm going to post a fix to clarify the language of the error.

Tuesday
Aug252015

What makes a good pull request description?

When you issue a pull request, you're saying, "I changed some code in this repository -- Please pull my change into the project." You should provide a PR description that tells reviewers what they need to know to evaluate your contribution. Better descriptions give better reviews, which end up with a higher-quality codebase.

Most PRs for a front-end web application should include all of these:

  • Purpose: what is this change trying to accomplish? Linking to specifications or tickets is fine, but you must include a one-sentence explanation in the PR description itself.
  • Approach: how does this change accomplish its goal? Explain your approach's architecture at a high level.
  • Worries: Is there anything weird here? Do you have any areas you want help?
  • Before & after screenshots, if the change is visual
  • How to use the feature or exercise the change. Just linking to a ticket with a bug description is not enough; tell the reviewer how they can verify for themselves that the feature is working as planned.

Larger PRs should also include:

  • Did you consider alternative approaches? Why did you go with the approach you chose?
  • How does this relate to other work? Link to other PRs or describe future plans.