• Response to The Thermal Printer Project: Part I

    by
    A few days ago, I decided to purchase the Adafruit Thermal Printer, which was compatible with the Raspberry Pi. This thermal printer has been on my mind for a while but this week a reason for buying one came to mind (aside from the fun of experimenting with a thermal printer which was obvious to me).
    Really enjoyed this series from James about hooking a thermal printer to a cronjob that'll print his weather, webmentions, and news off in the mornings. Brilliant! I've got some Pi's laying around collecting dust, I should use them for something fun like this.
  • by
    Expanded Tanzawa README instructions for running a local development version of Tanzawa using Docker. If you give them a whirl and they don't work or are confusing, let me know with a webmention, tweet, or opening an issue. 🙏🏻
  • by
    Got my Father’s Day present early! Woohoo ☕️🎉

    Cold Brew Coffee Maker

  • Writing Professionally in a Second Language

    by
    I just finished an article that will be published in this month's Web+DB Press magazine, a monthly web-related programming magazine in Japan. The entire magazine, including my article, is in Japanese. I want to reflect on the process of writing professionally in a second language and contrast this with my first experience when writing the 2nd chapter of Professional Python Programming 3rd edition (PyPro3).


    Picking a Topic


    Unless you're writing for yourself, the general topic is going to be decided for you. The company I work for writes regularly for Web+DB Press. GraphQL's been gaining popularity lately, and since I've built a few projects with it, a co-worker asked if I was interested in writing an article about GraphQL. Remembering how difficult it was to write PyPro3, I was a bit hesitant at first, but thought it'd be a good test to see how much my Japanese had I'd improved over the years. I also wanted share what I'd learned building GraphQL APIs with Django.

    Outlining


    Outlining is the process where you set the scope and decide in in more detail what you want to write about and the general order that you'll write. Before you can start outlining you need to first decide roughly how long of an article you want to write. The length of a magazine article is often decided for you, so it's mostly a matter of figuring out what you can fit into the allocated space.

    My outline was fairly basic, just a bullet list to help guide me along as I wrote and the base idea for what we'd build in the article.

    Writing


    Writing in your first language is difficult enough. Writing in a second language maintains the challenges of writing in your first, but also adds an extra layer on top. Not all idioms or expressions in your native language can be expressed in eloquently or in a similar manner in a different language.

    Having a solid outline of what you're going to write about, including the order and main points you want to cover makes writing much easier. This applies to writing in your first language as well, but it's doubly important in a second language.

    When writing PyPro3, I could write and speak Japanese, but writing a narrative piece was difficult. Many of the words I was using weren't quite yet internalized and reading what I wrote 5 minutes prior was a challenge. So I ended up writing the gist of what I wanted to say in English, and then translating it as best as I could before a native speaker cleaned it up for me.

    This time around, 3 years later, my outline was in Japanese and I didn't write any of the article in English first and then translate. Writing was a lot quicker too as I had become used to explaining code and what it's doing from work. I made the quickest progress when I was focusing on writing for a specific co-worker and explaining GraphQL to them.

    Editing


    Editing in a second language is difficult. I won't say I'm useless, but I don't have that feeling when something sounds "off" like I do with English. Without that sense, it was difficult to know exactly how to fix feedback from internal reviews and the editor at the magazine.

    The actual process of editing this time around was much easier, however. A co-worker and I would pair edit, where I'd pull up the document on my screen via Zoom and we'd work through the comments together. This made it much easier to ask for advice or for clarification or a second opinion. 

    Beyond not having a native feel for the language, skimming is also much more difficult. This makes finding the paragraph a particular comment is referencing a bit slow. I got better as I practiced, but I also found that copying a snippet of the comment and using the Find feature of my editor helped immensely. 

    Conclusion


    Good writing in any language requires clear thinking and proper planning. Being able to stay in the same language for planning, drafting, and editing makes the entire process much easier. Having native speakers check and edit your work  allows you to gain a better understanding of your second language, not only at the grammatical level, but with sentence patterns and flow as well.

    I'm grateful to have been given the opportunity to be published, especially in my non-native language and hope I'll have another chance in the future.

  • How to Process Tailwind / PostCSS with Webpack

    by
    Usually when I work with webpack another tool I'm using generates the appropriate config for me and I can remain blissfully unaware of how it all works.

    With Tanzawa I've only been adding tooling when absolutely necessary. The other day I configured PostCSS and Tailwind with Webpack. It still required a bunch of searching and piecing together blog posts to get something that worked for me.

    Below is a list of facts that helped me figure out how to think about processing CSS with webpack.

    • As wrong as it feels, your entry point for processing your CSS should be a Javascript file.
    • Webpack by default does not output a separate stylesheet file. In order to output a plain CSS file, you must use the MiniCssExtractPlugin.
    • Despite wanting to output only CSS, and specifying the filename in the options (style.css), Webpack will create an empty Javascript file regardless. There isn't a way to prevent this unless you add another plugin. I'm adding it to .gitignore.
    • The "use" plugins have the following roles
      • MiniCssExtractPlugin: Exact built css to a dedicated css file.
      • css-loader: Allow you to import css from your entrypoint Javascript file
      • postcss-loader: Run postcss with your 

    // webpack.config.js
const path = require('path');
const MiniCssExtractPlugin = require('mini-css-extract-plugin');

const tailwindConfig = {
  entry: "./css/index.js",
  output: {
    path: path.resolve(__dirname, "../static/tailwind/"),
  },
  plugins: [
    new MiniCssExtractPlugin({ 
        filename: "style.css"
    }),
  ],
  module: {
   rules: [
    {
      test: /\.css$/,
        use: [
          MiniCssExtractPlugin.loader,
          { loader: "css-loader", options: { importLoaders: 1 } },
          "postcss-loader",
        ],
    },
   ],
  },
}
module.exports = [tailwindConfig]

    In order for postcss to play well with Tailwind and webpack, I needed to update my config to pass the tailwind plugin the path for the tailwind.config.js. It simply imports (requires) the tailwind config and immediately passes the path.

    // postcss.config.js
module.exports = {
  plugins: [
    require("tailwindcss")("./tailwind.config.js"),
    require("autoprefixer"),
  ]
}

    Finally to run this all for production, I execute via webpack as follows. I still need to figure out how to get the NODE_ENV environment variable set via with the webpack --production flag, so for now it's a bit redundant.

    // package.json
{
  ...
  "scripts": {
    "build": "NODE_ENV=production webpack --mode=production"
  }
  ...
}
Previous 279 of 719 Next