サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
ブックレビュー
recompile.net
この記事では、Autodesk Fusion 360 でアルミ切削加工キーボードケースを設計する手順について説明します。 Fusion 360 そのものについては、扱いやすいソフトウェアでありチュートリアル記事が豊富にありますので、ここではキーボードケース設計に必要なポイントを中心に説明をしていきます。 本記事は、キーボード #1 Advent Calendar 2020 の 16 日目の記事です。前日はきせのんさんの 「2020年キースイッチ関連の回顧」 、翌日は Pekaso さんの記事です。 はじめに 日本の自作キーボードコミュニティでは、ケースの構造として基板をアクリルやFR4のプレートで挟むサンドイッチ構造が主流となっています。この構造は、比較的容易に設計できることや、安価に製造できるなどのメリットがあります。 一方、海外のカスタムキーボードは、アルミ切削加工でつくられたケースが
最近、巷でカスタムキーボードが話題になっているので調べてみました! 本記事は、キーボード #1 Advent Calendar 2019の19日目の記事です。 カスタムキーボードって何? カスタムキーボードとは、メカニカルキーボードの組み立てキットのことです。カスタムキーボードにはキースイッチやキーキャップがついていないので、自分で好きなものを選んで組み立てるので、カスタムという名前が付けられたそうです。普通のキーボードと比べても打鍵感や打鍵音が素晴しく、デザイン性に優れたものも多いので、趣味として収集している人も多いとのこと。 海外のredditというサイトでは、カスタムキーボードの条件として、市販品やその改造ではないこと、金属製のケースであることが挙げられていました。カスタムキーボードのケースは、アルミのかたまりをコンピューター制御で削り出してつくられるようです。また、ケースには真鍮製
技術書典7 で国内初(?)のカスタムキーボード入門書を頒布しました。『Learning Custom Mechanical Keyboard』(通称:白ウサ本)は、最高の打鍵感・打鍵音を目指すカスタムキーボードの入手方法から部品をどう選ぶか、潤滑の仕方など、必要な知識を余すところなく解説する書籍です。電子書籍は BOOTH で、紙書籍は遊舎工房さんの店頭でご購入いただけます。 という宣伝もあるのですが、今回は技術書典になぜ出展したのかという、ちょっと別の話をしたいと思います。 私は、文章を書くのが苦手です。こう言うと、あまり信じてもらえないことが多いものの、嘘偽りがない気持ちです。私自身は本が好きな方ですし、人よりも本を読む方かなと思っています。それでも、私は文章を書くのが苦手です。きちんとした文章しか書けないというよりも、書くのに時間がかかるタイプです。 中学の頃の国語の先生が教えてくれ
ソフトウェアエンジニアにとって、キーボードは仕事道具です。プロフェッショナルにとっての仕事道具とは、まさに、こだわりの対象であり、ソフトウェアエンジニアにとってのキーボードはこだわりの対象であるべき存在です。 最近でこそ、「こだわり」という言葉をポジティブな文脈で使うことが多くなってきています。しかしながら、本来「こだわり」は「気にしなくてもよいことまで拘泥する」というネガティブな表現でした。 その意味で、キーボードこそまさに原義に近いこだわりの道具です。バックリングスプリング式にこだわる人、静電容量無接点方式にこだわる人、そしてメカニカルキーボードにこだわる人。キーボードにまつわるさまざまな主義主張がそれを証明しています。日常的な仕事道具だからこそ、こうあるべきだという瑣末な違いについて、気になってしまうのです。 こうなるとキーボードにこだわりがないということですら、党派性を帯びてきます
同僚と自作キーボードについて話をするたびにでるのが、分割された Happy Hacking Keyboard ( HHKB )が欲しいという声です。 HHKB はプログラマーに人気のキーボードですから、その声が上がるというのも理解できます。そして、一般的に手にはいる自作キーボードキットで、そのまま HHKB レイアウトのものというのは見当たりません。それなら、自分つくってしまいましょうという経緯で生まれたのが Choco60 です。甘くて、みんなが欲しがるチョコレート、 Choco60 はそんなキーボードであったらいいなと思っています。 Choco60 は、私が設計、開発した自作キーボードです。いわゆる 60% キーボードのカテゴリーで、 62 キーのキーボードです。 Cocoa40 の姉妹モデルとして設計してあります。 一番の特徴は、いわゆる HHKB 配列を採用していることです。HHK
ふだん使っていても、手になじむもの、心地のよいもの、心がひかれるもの、そういうものがあります。触れるたびにその良さを発見し、おもわず嬉しくなってしまう、そういう道具に囲まれて暮らしたいものです。そして、自分でつくったものがそういう道具であれば、すごく素敵なことだと思いませんか? Cocoa40 は、そういうものであって欲しいという願いを込めたキーボードです。 Cocoa40 は、私が設計、開発した自作キーボードです。いわゆる 40% キーボードのカテゴリーで、 46 キーのキーボードです。数字キーの列がないキーボードですから、コンパクトですっきりとした見た目です。 このサイズのキーボードは実用的ではないと思われがちなのですが、一般的なキーボードに比べて運指の面で優れています。ホームポジションから、上と下の列にひとつだけ指を動かすだけですので、キーを打つときに大きく手を動かさずに済むのがメリ
今までよく知っていたはずのものが、よく知らないものになってしまう、そんな経験はありませんか? たとえば、濃霧。よく知っているはずの場所なのに、まったく違った風景が広がり、自分がどこにいるのかすら分からなくなってしまいます。ただの自然現象なのに、自身で確固たるものだと考えていたものが揺さぶられます。私にとって Nomu30 は濃霧のように、タイピングとは何か、キーボードとは何か、今までとは違った視点から考える機会となりました。 Nomu30 は私が設計、開発をした自作キーボードです。キー数は 31 で、いわゆる 30% キーボードのカテゴリーになります。 キーが行方向にずれて配置されている row staggerd な配列で、自作キーボードでよく採用されている格子状の ortholinear や列方向にずれた column staggered な配列になじみがなく、ちょっと敬遠しているという
キーボードの世界に足を踏み入れてから約半年、ようやく自分で満足できるキーボードを組み立てることができるようになってきました。熟達(マスタリー)には時間がかかります。 KBD67 は、自分の成長を感じることができる一台になりました。 KBD67 は KBDfans から発売された 65% キーボードです。ケースはアルミニウム合金である A6063 を削り出してつくられています。オプションでプレートの材質を真鍮に変更したり、ホットスワップに変更したりすることができるので、真鍮プレート、ホットスワップのオプション両方を選びました。 ホットスワップを選んだときには、キー配列が固定となるので注意してください。 101 キーボードの 2U のバックスペースの部分が Happy Hacking Keyboard のような 1U のキーが二つになっています。また、分割スペースバーにも対応していません。 ア
現在、世界的にキーボードが割れる病気が流行っているのを知っていましたか? 私も不幸なことに、キーボードが割れる病気に罹患してしまい、気付いていたら、 Keebio Fourier という自作キーボードのプリント基板(PCB)を発注していました。おそろしいものです。 Fourier は、40%キーボードを分割したキーボードです。ファンクションや数字の行がないコンパクトなサイズになっています。ミニマムでストイック、こんなのを使いこなすのって、なんだか格好よいですよね。 準備 キーボード用パーツ Keeb.io のサイトからは Fourier の PCB とプレート、分割されたキーボードをつなぐためのTRRSケーブルを購入しました。エアキャップ付きのクッション封筒に入って送付してくれるのですが、UPSの配送がひどくて、袋がボロボロになっていてリセットスイッチがばらばらになっていました。 キースイ
先日、会社でライトニングトーク大会が開催されました。そこで micro:bit で micro:bit の紹介プレゼンをするということをしましたので、同じことをしたいという奇特な方のために構成などを説明いたします。 micro:bit とは? micro:bit とは、英国 BBC が開発した教育用のマイコンボードです。 5cm × 4cm の小さなボードに表示用の LED が 25 個とボタンが 2 個、加速度センサー、磁力センサーなどが付いています。日本では、 スイッチサイエンス が販売代理店になっていて、オンラインで購入することができます。 開発環境 がウェブブラウザー上で動作するので、 micro:bit があればすぐにプログラミングを始められるというのが魅力です。 Scratch に似たブロックを組み合わせるプログラミングスタイルで、開発環境では簡単に JavaScript (正
キャスリーン・フリン『ダメ女たちの人生を変えた奇跡の料理教室』を読んだ。日経新聞の文芸書ランキングでみかけた後に、どこかで書評を読んで購入したのだったとおもう。 クックパッドに岡根谷さんという人がいる。コミュニケーション能力の塊みたいな人で、休暇のたびに日本中や世界中を飛び回って、色々な人の家庭の食卓に混ぜてもらうということをしているみたいだ。私にはとても想像がつかないので、西尾維新の小説にでてくる世界中を飛び回る委員長みたいだと畏敬しているのだけれど、その人が社内ブログに書いた文章で印象的な一文があった。フィリピンのスラムの家庭で過ごしたときの話だ。 スラムでお世話になった家族の素敵なところは、自分もお金がないのに、他所から来た人間のために惜しみなくお金を使って食べ物を与えてくれることです。……(中略)……一方で、数日いるうちに、お金を使うことによってしか自らの生活を作ることができないと
Railsを使ったアプリケーションの特定の場面では、「サービスレイヤ」や「サービスオブジェクト」という概念を導入すると有効に機能することがあります。今回は、その紹介をします。 まず、サービスレイヤとは何でしょうか。『Patterns of Enterprise Application Architecture(以下、P of EAA)』では「サービスレイヤは利用可能な操作を定め、各操作へのアプリケーションレスポンスを取りまとめる」と定義されています(参照)。ユーザーインタフェースなどからの呼び出しを受け付けるアプリケーションの境界として、ビジネスロジック、トランザクション制御、レスポンスなどの取りまとめをするのが、サービスレイヤの役割です。 では、どのようなときにサービスレイヤを導入するのでしょうか。P of EAAには、次のように記述されています。 You probably don’t
オライリー・ジャパン様から『マイクロサービスアーキテクチャ』をいただきました。出版記念イベント のお手伝いをさせていただいてる関係です。ありがとうございます。 本書はマイクロサービスにかかわる幅広い領域を扱っています。マイクロサービスの概念に始まり、アーキテクトとして検討すべき項目は何か、サービスの粒度をどのように決定するべきか、どのようにサービスをインテグレーションするのか、どのようにモノリスを分割していくのか、デプロイをどうすべきなのか、テスト戦略をどう考えればよいのか、監視やセキュリティをどうするのか、開発組織をどう構築するのか、大規模な環境での注意点は何か、などなど内容は多岐に渡ります。 それぞれの項目ついて詳しく解説しているというよりも、それがマイクロサービスというコンテキストに置いたときにどのように考えるべきなのか、ということが触れられています。個々の要素についてより深く知りた
デブサミ10周年記念に翔泳社で「君のために選んだ1冊 ソフトウェア開発の名著100」という本を企画されているそうです。カリスマプログラマからCIOまで、業界を代表する100人に書籍を推薦してもらうという企画だそうで、光栄にもお声がけいただき、原稿を書きました。私は、「アーキテクトを目指している現場のエンジニア」に向けての推薦図書というテーマで書いています。原稿をブログに掲載してもよいということでしたので、掲載します。 読者のみなさんで「アーキテクトを目指している」という方はいますか。そういった方は、アーキテクトにどのようなイメージを持っているのでしょうか。アーキテクトと呼ばれる理想の先輩がいるという漠然としたイメージかもしれませんし、スキルイメージを持って努力しているという方もいるのかもしれません。 実際、アーキテクトという言葉は色々な意味で使われています。スキルとして捉えられていることも
アジャイル界隈では次のような「ニワトリとブタ」の寓話をみかける。 ニワトリとブタがいた。ニワトリは「さあ、レストランでもやろうよ」と言った。ブタはよく考えてから「レストランの名前は何にしようか」と言った。ニワトリは答えた。「ハム・エッグさ」。ブタは言った。「僕は止めておくよ。君は産むだけだけど、僕は切り刻まれるんだよ」 これは、デイリースクラムミーティングでの参加や発言権についての話で、シュエイバー・ビードル共著の「アジャイルソフトウェア開発スクラム」(ピアソン・エデュケーション)で紹介されている。デイリースクラムミーティングについて、管理者やプロダクトオーナーなどの参加を許可しているが、発言権をなくし、その人数も最小限に留めるべきだとしている。 ウェブでは正確な引用元が記載されていることが少なく、邦訳の入手が難しくなってしまったという事情もあり、ここに引用しておく。
マイクロサービス(microservices)という言葉をご存知でしょうか? 今、エンタープライズ界隈のソフトウェアエンジニアの間でマイクロサービスという言葉がにわかに盛り上がりつつあります。 マイクロサービスはJames Lewis氏によって提案された言葉です。詳細については、彼がMartin Fowler氏と共著で書いた「Microservices」という記事を参照してほしいのですが、ようするにひとつのアプリケーションを、Railsのような一枚岩のアーキテクチャではなく、複数の軽量なサービスを連携させたアーキテクチャでつくろうというアプローチです。 上述の記事 では、マイクロサービスの特徴が九つほど上げられています。 サービスによるコンポーネント化:ライブラリではなく別プロセスで動作するサービスによってアプリケーションのコンポーネント化を実現している。 ビジネスケイパビリティに基づく組
ソフトウェア開発でのテストとは何かを単純に言うと、成果物が期待通りであるかを検証する作業といえる。こう動作してほしいという期待を入力に、成果物がその通りに動作するかを検証するのがテストである。 となると、成果物とは何で、期待とは何かが問題になるのだけれど、これが一筋縄ではない。というのも、システムは十分に複雑なので、ある部分を複数の部分に分けることもできるし、その部分をより大きな部分のパーツにすぎないとみなすこともできるからだ。 だからといって、一番大きな単位でもって期待通りにあるかどうかを検証すれば済む話かというとそういうわけでもない。というのも、大きな単位には大きな単位なりの期待が、小さな単位には小さな単位なりの期待というものが存在するからだ。 システム開発は、ひとつのものさしではかることができない。システムをつかって業務を遂行できるかという検証と、その部品であるクラスの検証では、成果
ActiveRecordを何も考えずに複数スレッドが動作する環境で利用すると、スレッド毎にActiveRecordがコネクションを確保しようとするので、プールサイズを超えてコネクションが確保できないというエラーが発生する。 activerecord-4.1.1/lib/active_record/connection_adapters/abstract/connection_pool.rb:190:in `block in wait_poll': could not obtain a database connection within 5.000 seconds (waited 5.001 seconds) (ActiveRecord::ConnectionTimeoutError) こちらとしてはコネクションプールがあるのだから、ActiveRecordの方でやりくりをしてよろしくやっ
最近、新人のテストコードを見る機会があり、ユニットテストの書き方について考える機会があった。ユニットテストはテンプレートみたいなものがあるので、それさえ押さえれば、誰でも簡単に書くことができる。 ここでは、その方法について紹介したい。サンプルはRSpecで書くが、その他のユニットテストフレームワークでも、応用ができるとおもう。 はじめに ごく単純化すると、テスト対象は状態を持ち、入力を与えると何らかの出力を行なうものである。入力が変われば出力は変化するし、状態が変化すると入力が同じでも出力が変わる(かもしれない)。 ユニットテストは、テスト対象の状態を操作し、与えた入力によって意図通りの出力を得られるかを確認する作業のことをいう。なので、ユニットテストを書くときには、オブジェクトの状態ごとにメソッド単位で入力と出力を確認するようにする。 RSpecの疑似コードで書くと、次のようなテンプレー
JUnit 4.4から組み合わせを表現するためのTheoryという機能が導入されています。このTheoryという機能について、日本語での概説がなかったため、調べた範囲で紹介したいとおもいます。 Theoryの実行 Theoryは組み合わせテストのための表現方法です。Theoryを利用するためには、@RunWithアノテーションでTheoriesランナーを指定します。すると、@Theoryアノテーションが指定されたメソッドが実行されます。 @RunWith(Theories.class) public class HelloTheoryTest { @Theory public void helloTheory() { System.out.println("Hello, Theory!"); } } 出力は下記の通りとなります。 Hello, Theory! DataPointの指定 @D
デブサミ10周年記念に翔泳社で「君のために選んだ1冊 ソフトウェア開発の名著100」という本を企画されているそうです。カリスマプログラマからCIOまで、業界を代表する100人に書籍を推薦してもらうという企画でそうで、光栄にもお声がけいただき、原稿を書きました。私は、「アーキテクトを目指している現場のエンジニア」に向けての推薦図書というテーマで書いています。原稿をブログに掲載してもよいということでしたので、掲載します。 読者のみなさんで「アーキテクトを目指している」という方はいますか。そういった方は、アーキテクトにどのようなイメージを持っているのでしょうか。アーキテクトと呼ばれる理想の先輩がいるという漠然としたイメージかもしれませんし、スキルイメージを持って努力しているという方もいるのかもしれません。 実際、アーキテクトという言葉は色々な意味で使われています。スキルとして捉えられていることも
March 17, 2010 新社会人のためのスーツ入門 ここに書いて誰が得するのかわかりませんが、まとめたので参考にしてください。服装は、自分のためでなくて会う人のためのものです。身だしなみは、自分が好きなものではなく、会う人が良いと感じるものにしましょう。 スーツ サイズ まずは一着、イージーオーダーを頼もう。スーツは、自分の身体に合ったサイズのものを着るのが一番よい。ブカブカだったり、ピチピチだったりするスーツはだらしがない。自分のサイズを知るためにも、きちんとしたお店で採寸してもらうのが良い。自分のサイズがわかったら、ツープライス店でも、どこでも買うといい。 店 安いイージーオーダーの店をいくつか試してみたところ、花菱縫製が値段が安く、そこそこに流行を取り入れているため、バランスが良いと感じた。楽天ショップで共同購入など安くなっているときを狙うとよい。採寸は実店舗で行なってもらえる
March 01, 2010 東京Ruby会議03のつくりかた 東京Ruby会議03が無事に終了しました。講師のみなさん、ご来場者のみなさん、スタッフのみなさん、本当にありがとうございました。 講演はどれもすばらしい内容で、平易な内容からひとつひとつ組み立てていって、高度な内容にいたる構成になっていて、とても理解しやすかったです。知っているようで知らない、使っているようで使えていない、そういう題材がテーマになっていたので、どれも興味深く聞くことができました。どの講演も「自分の道具を知ることで、自分を知る」という東京Ruby会議03のテーマにそった内容になったのではないかとおもっています。 それから、ワークショップの評判もよかったですね。こちらは、多種多様な内容でRubyの層の広さを伝えることができました。実のところ、ワークショップというのは、私の初期構想にはいっていませんでした。他のスタッ
February 15, 2010 LightRoomでトイカメラ風クロスプロセス現像 LightRoomでトイカメラ風クロスプロセス現像をする手順について説明します。LightRoomを利用すれば、こうしたことも簡単にできるのでオススメです。今回は、LightRoomの機能を利用して、次の画像のようにRAW画像を現像していきます。 0. 元画像を用意する 最初に写真を撮りましょう。ブログの記事を書こうと思いたったところ、目の前にミカンがあったので、それを撮りました。 1. 正方形にトリミングする トイカメラで利用されるブローニーフィルムでは、6×6cm判といって正方形の写真が撮れます。まずは、それっぽくするためにトリミングをしましょう。メニューの「表示」から「切り抜き」を選択します。このとき表示されるガイドは、デフォルトの「3 × 3」ばかりではありません。「表示」から「ガイドオーバーレ
February 12, 2010 アジャイルソフトウェア開発と人月商売 アジャイル開発では、人月商売をやらざるをえない。これは、大部分のプライムコントラクタと呼ばれるSIerにとって受け入れ難い選択肢だ。もし、アジャイル開発を導入したいのなら、まず契約について考えるべきだ。 業務委託契約には、請負契約と準委任契約という2つの形態がある。請負契約は、仕事の完成を約束し、それに対して対価を受け取る契約である。準委任契約は、善良な管理者の注意をもって委任された事務の処理を行なう契約である。 アジャイル開発は、開発中のスコープ変更を許容する。つまり、事前にどのような仕事を完成させるかということを決めることができない。そうすると、どのような仕事を完成させるか決める請負契約は結べないことになる。これは当然のことだ。 では、準委任契約にすれば良いかというと、そうそう単純な話ではない。受注者側、発注者側
December 06, 2009 札幌Ruby会議02へ参加しました ライトニングトークで発表をしましたので資料を公開します。 JRuby最新事情@札幌View more presentations from Naoto Takai. それから、Twitterのしすぎでまとまった文章を書けなくなったので、箇条書きで感想を挙げます。 北海道の空気はピリっとした寒さだった 札幌は道が無駄に広い人工都市 Ruby札幌の運営能力はすごい えにしテックがすごい ソースコード分が少ないかとおもったけど、そうでもなかった あらためてみると練られたプログラムだ スピリチュアルスライド芸に磨きがかかっていた というか稲作農家がやばい 飲まないと人見知りなので懇親しきれなかった 来てる人をどこまで撮影していいのか悩むなあ えにしさんをテックさんが抱き寄せながら夜のすすきのに消えていった 2連続舟盛りはキツい
November 06, 2009 東京Ruby会議03スタッフ募集 2月28日(日)に開催する東京Ruby会議03のスタッフを募集しています。 スタッフに参加される方は、下記のようにCcに takai@recompile.net を追加したうえで、 tokyorubykaigi03-staff@qwik.jp までご連絡ください。近日中にスタッフキックオフミーティングを開催する予定です。 Subject: 東京Ruby会議03スタッフになりたい! To: tokyorubykaigi03-staff@qwik.jp Cc: takai@recompile.net 本文に簡単な自己紹介をお願いします。
July 20, 2009 RubyKaigiについて話す前にRubyKaigiのことを話そう おそらく今日しか書けないエントリーを書こう。 日本Ruby会議は奇跡がおこる場だ。これは、もう奇跡としか言えない。世界中から今まで会ったことがないような人たちが集まって、みんな幸せで、みんな笑顔で、何かを伝えたり、やる気や勇気をもらったり、あげたり、一つの問題を考えたり、別々の問題に気付きあったり、本当に特別なことが起きている。しかも、そこらへんで、なんともないような感じで、なんともなく起こっている。 これって、論理的に考えてみれば、当たり前じゃなくて、むしろ、こんなことは有り得ないことだとわかる。本当に、RubyKaigiの個々のオペレーションというのはひどくて、薄氷を渡るというよりも、踏み抜くような準備しかできていなかった。また、Rubyistというのはプログラマの三大美徳が服を来て歩いてい
July 19, 2009 日本Ruby会議2009のスタッフたちです! ビアバッシュのあとに撮影しました。全員じゃないけれど集合写真です。かずひこさん、目立ちすぎ!
次のページ
このページを最初にブックマークしてみませんか?
『recompile.net』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く