ぼくの最強な在宅オーディオ環境
最強の定義には個人差があります。
2020年2月頃から在宅ワークをしているので、気がつくと一年以上自宅で仕事をしてることになりました。個人的にオーディオ機材が好きということもあり、個人の最強なオーディオ環境を半年ほど模索し続けていましたが、なんだか固まりつつある感じがしてきたので、ここいらでいったんまとめとして記事にしてみようと思います。
なお、冒頭にも書きましたが、最強の定義には個人差がありますのでご了承ください。
在宅オーディオ環境に求めるもの
ぼくが在宅オーディオ環境に求めるものは、以下の2点です。
- スピーカーとヘッドホンを併用するので、なるべくスムーズに行き来できるようにしたい
- オンライン会議のときのマイクも、同じ環境でモニタリングできるようにしたい
せっかく電話もならない（もともとオフィスにも電話はなかったですが）ホームオフィスなので、いい音で音楽を聴きたいです。ゆったりと聴くときはスピーカーで、集中するときはヘッドホンで音楽を聴きたいと考えたときに、それぞれをスムーズに行き来する環境が必要です。また、オンライン会議をするときも USB マイクやらイヤホンマイクをぶっ刺して macOS のオーディオ設定を変えたりとかも面倒なので、できれば同じ環境でまかないたい。
となると、必要になってくるのは。。。
- オーディオインターフェース
- XLR接続できるマイク
このあたりですね。
オーディオインターフェースで入出力をまとめる
出力だけで考えれば USB DAC でも良かったのですが、オンライン会議で自分の声が聴こえないと話していて気持ち悪ので、ゼロレイテンシーでダイレクトモニタリングができるオーディオインターフェースを使うことにしました。
巷では多種多様なオーディオインターフェースが販売されていますが、ぼくが必須だと考えた機能として、オーディオインターフェース単体で入力レベルを確認できるということがあります。久しぶりに DTM やら宅録もやろうかなとも思っていますが、直近ではオンライン会議で話すことがメインなので DAW とかは立ち上げないゆえ、入力レベルを監視できる機能がオーディオインターフェース自身に必要と考えました。
そこで購入したのが MOTU M2 でした。
M2 には入出力レベルを確認できるちっちゃなディスプレイがついており、これがとてもなめらかに動いていていい感じです。密度が高い音もとてもよく、音楽を聴いていてとても楽しい。
。。。だったのですが、会議で使っている Zoom のクライアントアプリでなぜか音声にデジタルノイズが乗ってしまいます。品薄で国内ではなく米国の B&H で購入したため、頑張って英語でやり取りをして交換してもらうために返送したのですが、在庫がないらしく返金対応に。。。（送料と関税が返ってこなかったので、5千円ほど損してしまいました。無念）
で、次に白羽の矢を立てたのが Audient evo 4 です。
ハードウェア自身にレベルメーターがついているものをずっと探していたのですが evo Control というアプリケーション上でそれが見れるらしく、なんならハードウェア上の操作がすべてアプリケーションでもできるようで、こっちのほうが便利そうだなと思い、購入しました。
実際に購入し使ってみていますが、マシン側で操作・確認できるのはけっこう便利です。evo 4 で操作される入出力レベルは macOS のAudio MIDI設定の入力・出力と連動しているため、たとえば、キーボード側で操作した出力レベルの上げ下げも反映されます。音もクリアで悪くないです。（ただ、音自体は M2 のほうが好みなので、国内の品薄が解消してぼくの懐の余裕も出てきたらまた使ってみたいですね）
コンデンサーマイクを購入
10年くらい前に購入した SM57 というダイナミックマイクを引っ張り出し、オーディオインターフェースにつないでみたのですが、ゲインが低くちょっと使いづらかったのでコンデンサーマイクを購入することにしました。
そのうちまた宅録とかで使うかもだけど、そこまでお金をかけたくないという絶妙なラインで探していたところ AKG P220 がちょうど良さそうだったので購入しました。
audio-technica AT2020 やら AT2035 も候補に上げていたのですが、ヘッドホンも K271 STUDIO ( Made in Austria ) を愛用している自分としては、やっぱりマイクも AKG がいいなと。一万円ちょっとでハードケースとサスペンションホルダーがついてくるのも嬉しい。
合わせてマイクスタンドも買ってしまおう！と TAMA MS205BK を購入。K&M よりも丈夫なので好きです。
机に付けるやつも考えましたが、やっぱマイクスタンドのほうがテンション上がります。
ポップノイズ対策で TOMOCA MS-140 も買いましたが、ちょっとでかすぎたので別のものを探しています。
開放型のヘッドホンがほしい！
上記した K271 と YAMAHA MSP3 というニアフィールドモニタースピーカーを所有しているため、出力側はとくにそのままでいいかな？と思っていました。
（新しく出た MSP3A も気になる）
ですが、密閉型の K271 でオンライン会議をしていると、ダイレクトモニタリングをしているとはいえ、やっぱりけっこう圧迫感があります。いわゆるテレカンには密閉型ではなく開放型のほうがいいのかな？と思い、かつ開放型のヘッドホンは所収していないので試しに買ってみることにしました。
開放型なら SENNHEISER でしょう！となり HD600 あたりを見ていましたが、ちょっとお財布事情的に厳しい。。。（ここまでけっこういろいろ買ってますからね。。。）
ならやっぱ AKG だな！となり K271 と同じ STUDIO の名がつく K240 STUDIO を購入しました。
ド定番なのでハズレということはないですし、実際に AKG っぽいいい音です。
最後に
以上、ぼくの最強な在宅オーディオ環境でした。ご参考までに。
最後に、最強の定義には個人差がありますのでご了承ください m( )m
33歳フロントエンドエンジニア（仮）の苦悩
追記
この頃はちょっとネガティブが過ぎました。やや病み気味だったですねぇ。今はだいぶ元気です。
いろいろと吹っ切れた部分もあるので、近々、記事にしたいと思います。
株式会社ゆめみという会社で働いている、会社員の大塚です。表題では「フロントエンドエンジニア」としていますが、「フロントエンドエンジニアとは？」という疑問を一年以上考え続け、まだ答えが出ていないので（仮）とさせていただいております。（よって、会社員と名乗っておりますｗ）
Web 制作現場のマークアップエンジニアから転職してフロントエンドエンジニアを名乗るようになったのですが、最近、自身のやりたいこと・できることが迷子になり少し負の感情に飲まれ気味だったので、転職してから現在までのこととや今の気持ちの整理をここに書いていこうと思います。
（何かが解決する記事にはならないのですが、自分のキャリアに似ている社内のエンジニア何名かと話をしてみたところ、どうやらみな同じようなことで悩んでいるようでしたので、答えはお教えできないけど、同じようなことで悩んでいますよとお伝えできれば幸いです）
入社までの経歴
前職ではマークアップエンジニアとしてコーポレートサイトやキャンペーンサイト、 LP と言った、いわゆる Web 制作の現場で働いていました。そこで培ったものは、 Qiita の記事にまとめています。詳細は Qiita の記事をご覧いただければですが、ざっくりいうと HTML, CSS, JavaScriptを駆使して、デザイナーが作ったデザインをブラウザで表現することをやっていました。
今の会社に転職した理由はいくつかありますが、そのひとつが SPA を使って Web サービスをつくるようなフロントエンドエンジニアの仕事がしたい！でした。その希望は叶うわけですが、ここから前述した自身のやりたいこと・できることが迷子の状態になっていきます。
転職から現在まで
転職し、フロントエンドエンジニアとして働き始めたわけですが、ここからいろいろと悩むことが増えました。前職でも同じような悩みを抱え、マークアップエンジニアからフロントエンドエンジニアになってみたのですが、悩みは減りませんね。
ちなみに、最近は気持ちがマイナス気味ですが、悩みと同じだけ新しいことにチャレンジできる楽しさや、学びが成長につながっている充実感もあるので、つらくて仕事をやめたい！みたいなことはないです。
はじめての React × TypeScript × テスト
今ではこのレベルであればとくに苦労なく実装できますが、転職したばかりのころは経験がない部分だったのでけっこうきつかったです。
React のコンポーネントを TypeScript で書くと、おそらく以下のようになるかと思います。
// ¯\_(ツ)_/¯
import React from "react";
interface Props {
text: string;
}
export const TextComponent: React.FC<Props> = ({ text }) => <p>{text}</p>;
TypeScript のレベルが低すぎて React.FC<Props> ってなんやねん？でした。
また、テストも一文字も書いたことがなかったので、そもそもテストとは？なんのためにやるのか？から勉強しました。（Jest のドキュメントをずっと開きっぱなしにしてました）
活躍できたコンポーネントづくり
しかし、ただつらいだけではありませんでした。 React を TypeScript で書く方法がわかってきてからは、前職で培った HTML と CSS の知識を活かせたコンポーネントづくりはとても楽しかったです。貢献できている手応えもありました。また、 React を通してデザインシステムの設計をより深く理解することができ、 CSS 設計力を伸ばすことができたかと思います。
プログラミング苦手問題
JavaScript はそこそこ書けるレベルだったと思うのですが、メインは HTML, CSS だったので、プログラミングは弱い部分でした。ビジネスロジックなんて単語は聞いたことなかったですし、みんながクリーンアーキテクチャや DDD みたいな話をしているときも ( ﾟдﾟ) こんな状態でした。
日々勉強はしているつもりですし、そこそこ書けるようになってきた実感はあるのですが、入社から約2年たってもまだ自信を持てない部分です。
そんな日々を過ごすうちに、「フロントエンドエンジニアの職域とは？なにができれば、フロントエンドエンジニアなのか？」ということを考えるようになり、いまの自分のスキルではフロントエンドエンジニアと名乗るのはおこがましいな思ってしまい、名乗るのをやめてしまいました。
スクラムマスターになってみる？
大きめのプロジェクトの主担当になったとき、開発部分よりも仕事の進め方やチームのあり方みたいなことを考えるようになり、ためしにScrum Inc.認定資格スクラムマスター研修を受けてみました。研修を受け、チームにどうフィードバックしていったか？についてはこちらの note を見ていただけばと思いますが、研修を受けたことにより、案件でも実際にスクラムマスターとして動いてみることになりました。
すこし note の続きになるのですが、研修で聞いたことをいろいろ試してみてもあまりうまくいっている実感が持てず、チームをよりよくするために動いているけど、もしかすると、悪くしてしまっているのではないか？と悩むようになりました。これに関しては、チームメンバーでもあるフロントエンドエンジニアの先輩方からいろいろとアドバイスをいただいたり、お話をさせてもらって、ひとりで抱えすぎていたことに気がつけたので、今はそこまで気持ちが落ち込んだりはしなくなりました。
その他、やってみたこと
仕事でさわることはないのですが、インフラのこととか全然知らなかったので、AWS を勉強しようと思い AWS 認定 ソリューションアーキテクト – アソシエイトを取得してみました。エンジニア同士の話についていけるようになっただけでも、勉強したかいはありました。
あと、プログラミングの基礎を学ぶため Java の学習を始めてみました。こちらも、なんとなく TypeScript を書き始めた自分としては、形のある言語の基礎を学べているのでとても有意義です。
フロントエンドエンジニアの苦悩
そんな経歴のわたくしですが、以下のようなことで悩んでおります。
自分はフロントエンドエンジニアなのか？
- React, TypeScript がそこそこ使える
- めちゃくちゃ高度なことはできないけれど、プロジェクトで困らない程度には使えている（はず）
- ロジック部分よりも、セマンティックなマークアップやデザインに寄り添いつつ破綻しないデザインシステムの構築が得意
- （一応）認定スクラムマスター
このスキルでフロントエンドエンジニアを名乗っていいのか？わからいので、名乗っていません。
結局のところ、何をどこまで出来ればフロントエンドエンジニアと名乗っていいのか全然わからなくて、もう一年以上名乗ってない。怖くて名乗れない。
— Otsuka Yuhi on YUMEMI lnc. (@otsukayuhi) February 9, 2021
こんな気持です。
けっきょく自分はなにがしたいのか？
- フロントエンドを伸ばしたい自分
— Otsuka Yuhi on YUMEMI lnc. (@otsukayuhi) February 12, 2021
- サーバーサイドやプログラミングの力をつけたい自分
- スクラムマスターとして、チームをよくすることに注力する自分
この3つが同時に存在しようとしているので、シュレディンガーの俺状態になっている
Twitter でこんなことをつぶやいたのですが、いまの自分の課題というか悩みは「けっきょく、自分はなにがしたいのか？」が決まらず、いろいろな方面に手を出して全部中途半端な状態になっているということです。
最後に
まとまりがない文章になってしまいました。まだ答えが出ていないので、この記事ではこれ以上書くことはないのです。ご勘弁を！
ぼくとゆめみの2019年
あけましておめでとうございます。2020年もよろしくおねがいします。
2019年の振り返りをしようと記事を書き始めましたが、ゆめみへの入社がとても大きな出来事だったので、そのへんが中心になっています。
転職しゆめみへ
2019年4月、約4年間お世話になった会社を退職し、株式会社ゆめみに入社しました。前職では、主に静的なWebサイト制作をしていました。流行りのVue.jsやReactみたいなものはほとんど使用せず、jQueryをガッツリな感じです。一転、ゆめみでは某ECサイトの案件にアサインされ、Reactを始めとした、いわゆるSPA周りの技術を触るようになりました。セマンティクスなマークアップやCCSでのスタイリングは得意ですが、ビジネスロジックや状態の扱いが不慣れなため、そこ重点的に勉強を頑張りました。
React / Next.js / CSS in JS (Emotion)
CSS設計でつくるUIコンポーネントに悩んでいた自分にとって、Reactは（今更ですが。。）革命的な技術でした。Next.jsもとても便利で楽しい。サーバーサイドJSの勉強にもなります。今後は、Webアプリ・サービスじゃない静的なWebサイトでもどんどん使っていこうと思っています。
このあたりの入門記事をQiitaでまとめていますので、興味のある方はどうぞ。
https://qiita.com/otsukayuhi/items/61163f4b0ee43e616e42
コードレビュー
コードを読むことが苦手だったので、前職ではほとんどやってこなかったマージリクエスト（プルリクエスト）によるコードレビューがとても勉強になりました。また、1行単位でレビューしていただくことで、品質も担保されているので安心感が違います。もう、レビュー無しの現場に行くの怖いですね。
ゆめみの制度
ゆめみにはユニークな制度が多いです。
https://note.com/raykataoka/n/n28ec5cfce0b8
ぼくも全部利用しているわけではないですが、給料を自己申請で決めたり、資格取得報奨金制度でAWS認定クラウドプラクティショナーを取得して報奨金を頂いたりしました。中にいると慣れてしまいますが、外の方とお話するとやっぱりおもしろい会社だなと再認識します。
ゆめみで自由を知った
大層な表題ですが、ゆめみに入社して「もっと自由でいんだな」と考えるようになりました。たとえば、最近マークアップエンジニア同士で交流できるようなコミュニティがないと思ったのでMarkupMeetupを作ってみたり、Reactが少しずつ使えるようになってきたのでそれをシェアする勉強会を主催してみたり。たぶん、前職にいた頃の自分では、ここまでの行動を起こしていないと思います。
MarkupMeetup
https://markup-meetup.connpass.com/
2020年の抱負
今年の抱負は研鑽にしました。学ぶこと・思考することを止めず、日々コツコツと成長していければと思います。あと、今年はフルマラソンに出場する予定です。大阪マラソンか神戸マラソンあたりに当選できたら嬉しいですね。
おまけ
ドラえもん50周年記念の節目に、JINSドラえもんモデルメガネを購入しました。良い。 https://www.jins.com/jp/collabo/doraemon/
エンジニア情報共有コミュニティ「ふわふわエンジニアタイム」発足のお知らせ
この度、エンジニア同士の情報共有を目的としたコミュニティ「ふわふわエンジニアタイム」を発足いたしました。「心理的安全性」を最重要においた、ノーマウントなコミュニティを目指しています。エンジニアであれば、経験問わずどなたでも参加できます。
以下、コミュニティの概要をご説明いたします。
概要
「ふわふわエンジニアタイム」は、Web周りの技術を話題の中心にした、情報共有のためのコミュニティです。Slackでのコミュニケーションをメインに考えていますが、定期的なオフラインでのミートアップ等もやっていきたいと考えています。
Slackでのルール
- 心理的安全性を第一とし、相手を萎縮させるようなマウント行為をしない
- 特定の個人・企業へのバッシングや個人情報が入った内容は投稿しない
- 情報を見やすくするため、見合ったチャンネルで発言をする
- 話題の混在を防ぐため、投稿はなるべくスレッドにまとめる *1
- なるべくパブリックチャンネルで会話する
- チャンネルの作成は自由に行ってよい
- 重複するチェンネルがないかどうか調べる
#everyoneで新規チャンネル名と概要をお知らせする
*1 
参加資格
- 一行でもコードを書いたことがある人
- 他者への思いやりある行動ができる人
参加方法
参加のご意思を、下記のTwitterアカウントへDMしてください。Slackへの招待URLをお送りします。
Twitter:@otsukayuhi
【リモートワーク、複業時代の「自分戦略」】に参加して思うこと
先日、DevLOVE関西主催のリモートワーク、複業時代の「自分戦略」に参加しました。中村さん、大西さん、コンチさんのお話を聞いたり、その後のダイヤログで参加者の皆さんとお話させてもらった中で、いろいろと思うところがあったので、それを書いてみようと思います。
単一組織に依存するリスク
組織に属するメリットは多いので、すべての人がフリーランスのような働き方をする必要はありません。ただ、所属する組織がひとつしかないような場合は、偏った評価やライフスタイルとマッチしないルール、収入の支配等のリスクが発生してしまう可能性があります。
複業や副業、兼業は、個人と組織の市場価値を高める
組織内でしか通用しないスキルは、その組織を一歩出てしまうとなんの価値もありません。大切なのは単一組織での価値を上げることではなく、市場での価値を上げること。自身の市場価値が高まれば、どこにいても活躍できます。
そのためには、組織の外で活動をする必要があります。せっかく習得したスキルが、組織外の市場で通用しない属人化されたものにならぬように、外に出て広い視野を持つことが大切です。
また、お金が絡むからこそ見えてくる、自分の価値があると思います。複業や副業、兼業が有効な手段として推奨されている理由はそこです。
そして、そういった活動が、結果として所属する組織をより強いものにするのではないでしょうか。
収入を分散して、経済的なリスクを減らす
収入を単一組織に依存させてしまうのは、とてもリスキーです。会社はいつ倒産するかわかりませんし、業績不振によって給料が減ってしまうこともあるかもしれません。収入の支配からの卒業が必要です。
複数の収入源を持っていれば、ひとつがダメになってしまったとしても、すぐに生活が破綻してしまうことはないでしょう。守るべき家族がいるのであれば、なおさらです。
ライフスタイルにあった働き方で、安心して生きる
ライフスタイルとマッチしないルールの元で働いていると、負荷が高まり心や体を壊してしまいます。また、多くの人に迷惑もかかります。各々が多種多様な問題を抱えているはずなので、その問題を解決できたり、少しでも軽くなるようなルールのもとで働くべきです。
たとえば、リモートワークは介護や子育てのために家を離れられない人たちにとっては、とても有効な手段・制度だと思います。私自身も、家族の体調不良のために出社が難しい経験をしていて、リモートワークの必要性を強く感じています。
組織のルールを変えるのは難しい
ダイアログでも出た話ですが、一個人が大きな組織のルールを変えることは難しいです。（そう簡単に一個人の意見で変わってしまうのも問題ですしね）説得材料を揃えてプレゼンしたり、組織内政治で根回ししたり。。。その時間をスキルアップや趣味、家族との時間にあてたほうがよっぽど有意義でしょう。
上記した複数や副業、兼業、リモートワークのような働き方は、多くの企業で取り入れられ始めています。正直なところ、組織を変えるよりも組織を代えてしまうほうが低コストです。（要は転職ってことです）
現在は売り手市場なので、転職者に有利な状態です。（リクルートのプレスリリースによると、2018年12月の転職求人倍率は1.65倍。エンジニアに至っては4倍程度もあるそうです。）各企業も、良い人材を確保するために制度の見直しや、新しい取り組みをしています。
上司は親ではないし、会社は家族ではありません。本当に大切なものは何か？そこを勘違いしないように気をつけなければなりませんね。
もし、組織を変えるための説得材料がほしいのであれば、厚生労働省の資料がありますので、参考にすると良いでしょう。
こちらからは、以上です。
「JavaScriptが使える」と言えない理由
un-T factory! XA Advent Calendar 2018 21日目の投稿です。
年の瀬ですね。
2018年はJavaScriptの学習に力をいれ、去年にくらべてスキルが格段に向上しました。一年前では書けなかったであろうコードを書いている自信はあります。
でも、まだ「JavaScriptを使える」と堂々と言えない。イマイチ自信が持てない。自分では結構勉強したつもりだったんですが、なんで自信が持てないのか？
来年への課題として、ちょっと考えてみました。
「書いてない」から「書けない」
12月20日時点で、エンジニアというか仕事というか、そういった類の書籍を22冊読みました。勉強会やセミナーにも、ちょいちょいでました。
具体的にはここにまとめています。 qiita.com
開眼！JavaScript、開眼させていただきました。2018年はJavaScriptの強化を大きな柱にしていましたが、この本を今年はじめに読んだおかげで、それがすごくスムーズでした。ES3の頃の書籍なので、モダンな記法は書いてありませんが、基礎を強化するには最適な書籍です。ES2015+版が出たら、200%買います。
あと、仕事で部分的にVue.jsを使ったので、基礎から学ぶ Vue.jsはかなり参考になりました。
が、それ以外のNuxt.jsやReactやAngularやWeb Componentsや（JavaScriptじゃないけど）Dockerや（JavaScriptじゃないけど）Ruby on Railsは、正直あまり書ける自信がない。
なぜかというと、手を動かしてないから。
書籍のラインナップだけみると、なんでも使えるウルトラフロントエンドエンジニアです。
でも、実際にプロジェクトで使ったVue.jsやwebpack以外は、ほぼ使えない。結局、手を動かしてない部分は、上辺の知識でしかないんですよね。
「書けない」から「読めない」
これは最近気がついたのですが、思った以上にコードが読めない。
リファレンスや書籍に書かれたJavaScriptは、きれいに書かれているし、記述量が少ないので読めます。でも、いざ、他人が書いたコードやライブラリのソースコードとなると、まぁ読めない。
本で読んでメソッド単体の動きを知っていても、それが単体で使われることはあまりありません。実際のプログラムは、複数のメソッドを使って複雑な処理をしています。実際に手を動かしてその経験をあまりしていないから、コードがスッと入ってこない。複雑なコードが読めないから、それ以上の知識として膨らまない。だから、また書けない。
「プログラミングができる」とは「読み書き」ができること
「書けない」から「読めない」。「読めない」から「書けない」。この繰り返しでなかなか前に進んでいないのだなと、今年を振り返って思いました。
ただ、これは逆に考えると、「読める」から「書ける」。「書ける」から「読める」になります。
たくさん書いてコードを書けるようになる。たくさん書けるようになるとコードが読めるようになるから、GitHubとかで世界中のコードが読めて、もっと書けるようになる。
来年はこのサイクルを早く手に入れ、「JavaScriptを使える」と、堂々言いたいです。
こちらからは、以上です。
ぼくがブログを書く理由
ブログを開始しました。
初回は、練習を兼ねてブログ開設までの理由や、過去の遺産を紹介したりします。
ブログはカテゴライズしづらい文章に向いている
文字情報を配信するサービスは、いくつかあります。
そのなかで、いまぼくがやっているものは、
こんなところでしょうか。
それぞれ、役割がはっきりしているため、投稿するときに迷うことが少ないのです。
たとえば、
こんな感じ。
（noteは、今後どんなものを投稿すればいいのか検討中。。。）
逆にいうと、上記のサービスに適さない文字情報は、投稿しづらいです。
ようは、この記事みたいなやつ。
Twitterじゃあ文字量がたりず、Facebookみたいにクローズドでもなく、Qiitaほど技術よりじゃない。
ブログってのは、そんな「カテゴライズしづらい情報の発信」に向いていると思う次第です。
はてブを選んだ理由
markdownが使えるから。これ、けっこう重要です。
過去の遺物
今までもブログ的なものはいくつかやっていました。
- バイト先のブログ（勝手に作った）
- 小説ブログ
- mixi
- その他、とりあえず開設したブログ
まあ、こういったものはだいたい黒歴史になる率が高いので、気がついたら処分してきました。
小説を投稿していたブログとかは、逆に今みたい感じありますがね。
が、ひとつだけインターネット上に残っているものがあります。
これ。
ぼくが今の会社にはいる前にちょっとだけやったいた、デバイス専門ブログ。
よくわからないままにWordPressでつくり、適当に広告をはりました。
開設から8年経っていますが、広告費が最低支払い料に達していませんｗ
とくに更新する気もないのですが、無駄に.jpドメインとかつかっているので、無くすのがなんかもったいなくて放置しています。
で、どんな記事を書くか？
今後、書きたいものは、こんな感じ。
- Webの技術のこと
- ハードウェアのこと
- 音楽のこと
- その他、人生のことやどーでもよいこと
基本的に、自分の備忘録的な内容になってしまうと思いますが、それでも、どうせ書くなら誰かに読んでもらったり、誰かのためになって欲しいものです。
そんな感じで、ぼくのブログ「ぼくがブログを書く理由」スタートです。
