サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
買ってよかったもの
blog.tai2.net
目次 CSS小史 SUIT CSS - 命名規約ベースのCSS方法論 styled-components - CSS in JS Tailwind CSS - Utility-first CSS なぜインラインスタイルではダメなのか まとめ タイムライン 参考リンク CSS小史 CSSでアプリのUIを実装するための手法は、これまでいくかの変遷を辿ってきた。 はるか昔、CSSが生まれて間もないころには、関心の分離という文脈から、FONT要素などの物理タグはよくないものとされ、 コンテンツ(HTML)とスタイル(CSS)をきっちりと分離することが奨励されはじめた。 そこでは、HTMLはあくまで文書であり、CSSのクラスセレクタという接点でコンテンツと見た目が隔離されることで、それらは別世界のものとして管理されていた。 また、大規模サービス開発においていかにCSSを管理するかという問題意識はまだ
最近ちょっと必要があって、DenoでCLIコマンドを作ってみた。 いままでこういったCLIコマンドはNodeやPythonで作ることが多かったのだけど、Denoの使いごこちが知りたくて作ってみたら、 思いのほかすごく快適だったので紹介する。 作ったのは、 decor というマークダウン変換ツールだけど、なにを作ったかよりも、 どう作ったかが重要なので、この記事では深掘りしない。 目次 Denoとは Deno気持ちいい プログラムの配布 ソースコード以外のアセットを配布する 依存モジュールの自動更新 マークダウンパーサー DOMパーサー まとめ Denoとは Denoは、Node.jsのクリエイターである Ryan Dahl が、 Node.jsでの反省点 を盛り込んで作り直したJavaScriptランタイム。セキュリティーを念頭に置いて設計されている。詳しくは検索してください。 Deno気
はじめに If you’re not paying for the product, you are the product itself. (製品にお金を払っていないということは、あなたが製品そのものということだ) これまで、しっくりくるメール受信環境がなかなかみつからず、いろいろな変遷をたどってきた。 Gmailを愛用していた時期もあったけど、あるとき、ふと開眼し、広告モデルのウェブメールをやめたいと思うようになった。 そこからは苦難の道だった。Mac標準のメールアプリは検索がときどきバグったり、フィルターがいまいちだったりした。 OSSを使って快適なCLIメール環境の構築を試みもした けど、ときどきバグってメンテが大変だったりした。 けっきょくのところ、いまどきローカルにメールボックスを持つのは特定のマシンに縛られて不便だし、自前で環境が壊れないようにメンテするのもしんどい。 かとい
コードレビューにずっと苦手意識を持っていた。レビューは時間がかかるし、あまり気が乗らない。 がんばってやっても、うまくできたのかどうか自信が持てない。 もちろん、世にあるコードレビューに関する書籍や記事などはいくつも読んだ。 そこには、コードレビューをするときの観点や、コードレビューで望ましい言葉づかいなど、ためになることがたくさん書かれていた。 それでも、やはりコードレビューが苦手なことに変わりはなかった。 だけど最近ようやく、こうすればレビューをうまくこなせるのではないかという出口が、なんとなく見えはじめてきた。 この記事では、ぼくなりにたどり着いた、プルリクエストのレビューを上手に行うための心構え、つまりいかにしてレビューのつらみを減らすかについて書く。 目次 なぜコードレビューはつまらないのか われわれは、なんのためにコードレビューをするのか レビューのコスト レビューの観点 文化
人月の神話 をひさしぶりに読んでみた。 人月の神話は、フレデリック・ブルックスの超有名古典的エッセイ集で、ソフトウェアエンジニアリングに関する多岐にわたるトピック取り扱っている。その中でもとくに有名で、よく世間で言及されるのは、表題にもなってる「人月の神話」と「銀の弾などない」、それから「セカンドシステム症候群」あたりだろうか。 はじめて読んだのは20年くらい前。社会人になったばかりのころ、満員電車にゆられながら、「へー人を増やしても開発ってうまくいかないのねー」などとわかったような顔をしながら読んでいたのを覚えている。当時は職業プログラマとしての経験を積む前で、本を読んでも鵜呑みにすることしかできなかった。でも、熟練のプログラマとして経験を積んだいま読んだら、またなにか違った洞察を得られたりするかもしれない。読み返してみた動機はそんな感じ。 目次 現代のプログラマにとって有益か やっぱり
ひょんなことから、長年やっていたフリーランスプログラマをやめて、 Autify というE2Eテスト自動化サービスを運営している会社の社員になり、一年が経った。 フリーランスプログラマ雑感 では、フリーランスプログラマ生活を振り返って、フリーランスプログラマの実態に興味がある会社員に向けて書いたけど、今回は逆に、会社員をやったことがないとか、ぼくのように、会社員だったのが昔すぎてどんなものだったのか忘れてしまったという方に向けて、会社員プログラマとはどういうものか説明する。 目次 Autify入社のきっかけ・動機 自営業→会社員 受託→自社事業 Autifyはどんな会社か 英語 技術周り まとめ Autify入社のきっかけ・動機 Autifyの開発には、正式リリース前から業務委託のパートナーとして携わっていた。で、しばらく働くうちに社員になりませんかという誘いを受けた。 その時点で、Auti
Gitには、リポジトリに含めたくないファイルを指定できる .gitignore というファイルがあります。 通常は、これ自体リポジトリにコミットされ、チームで共有されます。 この.gitignoreファイルに、 .DS_Store(Mac環境で自動的にOSが生成するファイル)や、.swp(vimが一時的に生成するスワップファイル)など個人環境に依存するファイルは指定すべきではない、という話をツイッターで見かけて気になりました。 筆者は、これまで、こういったファイルを積極的に指定するようにしていたからです。 .DS_Storeなどを入れるべきでない理由 .gitignoreに.DS_Storeやなどを指定すべきでない理由として上げられているのは、vimのユーザーが参加したら.swpを、 VS Codeユーザーが参加したら.vscode、Windowsユーザーが参加したらThumbs.dbとい
フリーランスプログラマになって、かれこれ10年近く経ってしまった。 昨日をもって退職しました。今日から(しばらくは)フリーランスとしてがんばります。 — 武藤スナイパーカスタム🔫 (@__tai2__) November 30, 2010 会社を辞めて、とくに深い考えもなくなんとなくフリーランスになった。しばらくすればどこかの会社に就職するのかなあ、きっとそうなんだろうなあ、とかぼんやりと思ってたことを考えると、そのまま10年近くも続けてしまったのは感慨深い。 ぼくにとって、ほかの業種、ほかの立場の人の職業生活がどういうもんなのかわからないのと同程度に、ほかの人にとってもフリーランスプログラマがどういうものか、きっとイメージがあまりわかないんだろう。そこで、フリーランスプログラマ生活を振り返って、それがどのようなものだったのかを思いつくままに語ってみたい。フリーランスプログラマという語は
この記事は ムラサメ研究所 学会 Advent Calendar 2018 の21日目の記事です。 現代的なOSであれば、ディスクから読み込んだデータをバッファーキャッシュ(UNIX系)あるいはファイルキャッシュ(Windows)などと呼ばれる RAM上の領域にキャッシュしておく機能があります(以降バッファーキャッシュで統一)。 したがって、同じファイルを2回以上読みこむと、2回目以降のほうが高速に読み込める見込みが高いです。1 本記事では、このことを実験的に確認し、その事実がアプリケーションプログラミングに与える影響を考察します。 目次 バッファーキャッシュとは 検証方法 検証用プログラム 検証結果 アプリケーションプログラミングへの影響 まとめ 参考リンク バッファーキャッシュとは バッファーキャッシュは、カーネルの管理しているメモリ空間に配置され、アプリのアクセスできるユーザー空間と
目次 バッケージの集合をまとめるためのパッケージを作りたい 問題 Nodeモジュールの検索アルゴリズム npm installのアルゴリズム yarnとnpmはinstallアルゴリズムが異なる 解答 まとめ バッケージの集合をまとめるためのパッケージを作りたい アプリに必要なプラグイン群への依存を別パッケージにまとめて記述しておいて、アプリはそのパッケージに依存するようにすれば便利ではないでしょうか? npmでこのようなメタパッケージを実現したい パッケージの依存関係をまとめるだけの、メタパッケージのようなものです。 そうすれば、アプリ自体のpackage.jsonは短くなるし、メタパッケージに必要なプラグインの選定を オマカセ できます。 しかし、Node.jsのパッケージシステム(npmとyarn)で、このようなことをやろうとすべきではありません。 このことは、以下の問題を考えること
問題 ReduxなどのFluxアプリケーションの実装では、アクションのフォーマットとして、 Flux Standard Action(FSA) を採用しているプロジェクトも多いと思います。 FSAを使って非同期アクションの結果を表現しようとしているときに、以下のような疑問を抱いたことはないでしょうか? たとえば、TODOアイテムの更新をするアクションとして、UPDATE_TODO:REQUESTED, UPDATE_TODO:RECEIVED という2つのアクションがあるとします。これらは、それぞれHTTPリクエストとレスポンスに対応します。 // リクエスト { type: 'UPDATE_TODO:REQUESTED', payload: { id: 100, text: 'Do something!' } } // レスポンス { type: 'ADD_TODO:RECEIVED',
最近話題の dev.to で、og:imageを記事タイトルから生成しているのが良かったので、 このブログでも 記事タイトルからog:imageを生成するようにしました 。 dev.toのog:imageは、 Cloudinary という、 URLのクエリ文字列で画像処理をできるSaaSを使って動的に生成していますが、本記事ではこれとは別のアプローチを取ります。 Pupeteer を使って自前で生成するというやりかたです。 Puppeteerとは Headless Chrome を操作するためのNode.js用ライブラリです。Selenium WebDriver と同じようなものですが、Chromeに特化していて、シンプルなAPIを持っているのが特徴です。npm installするだけでChromium1もいっしょにダウンロードしてくれるので、お手軽に使いはじめられます。 方法 og:im
はじめに Webpack、ES6風味のJavaScript、そして他すべてのモダンなクライアント側開発体験の進歩をまだ試していないなら、Webpacker 3.0は、はじめるのに絶好の機会だ。 —DHH Rails 5.1 で Webpacker が導入され、Railsでもモダンなフロントエンド開発が簡単にできるようになりました。 Webpackerはリリースからどんどん進化しており、 3.0でさらに使いやすくなりました。 本記事には2つの目的があります: RailsのAsset pipeline(Sprockets)をまったく使用しなくてもRails開発が可能であることを実証すること モダンフロントエンド未体験のRailsエンジニアに向けて、実際のコードをまじえつつ、モダンフロントエンド開発の雰囲気を伝えること また、Webpackerの概要を知りたいRailsエンジニアへの機能と使い方
React Reduxを使ってプロダクトを作りはじめて、かれこれ半年くらい経ちます。 しかし、どうもうまく書けていない気がすることがときどきあり、悩んでいたところ、ツイッターで次のような助言をもらいました。 @__tai2__ 達人かどうかは微妙なところがありますが、ある程度の規模のコードはここにリンク集あります https://t.co/B79B5s1DTe — Yuki Kodama (@kuy) 8 December 2016 この記事は、上記のリンク集でまとめられている実際のReact Reduxプロダクトのソースコードを調査することで、筆者がふだんReact Reduxで開発をしていて感じる疑問への答えを探る試みです。 筆者が答えを得たいと思っている疑問は次の3つです 1 Storeはどんな具合に階層化すべきか Store初期化(hydration)用データの定義はどうすべきか
先日、SNSで次のエントリを見かけました。 正規表現でのメールアドレスチェックは見直すべき – ReDoS ある種の正規表現をサーバー上で実行したときに、DoS攻撃に繋がるおそれがあるという指摘です。 ところで、そもそもメールアドレスの形式チェックはなんのために行うのでしょうか? ユーザーの正しいメールアドレスが muto@example.com のケースを考えます。 もしもユーザーが入力したメールアドレスが、mutoexample.com のように@マークが含まれないなど不正な形式であった場合、当然ながらユーザーのもとにメールは届きません。このようなミスは、たしかに正規表現等による簡単な形式チェックで防げるでしょう。 一方、たとえば、 nuto@example.com と入力してしまうような入力ミスは、形式的に不正ではないため正規表現では防げません。つまり、正規表現では、ユーザーの入力ミ
Symfony Advent Calendar 2015 7日目。 要約 Doctrine 2.4以降では: DQLでクエリを書く際に、 JOIN WITH構文を使用することで、 @OneToManyアノテーションなどで関係するプロパティを定義せずとも、 関係するエンティティを結合して絞り込みをかけることができる。 前提 JOINをしたいが、エンティティ間の関係を定義するほどではない。あるいは、プロジェクトのポリシーで、所与のもの以外には、@OneToManyなどの対多関係を追加しないということになっている。 例題 以下の、ブログポストへのタグ付けを意図した多対多の関係を考える。 postテーブル id title 1 Symfonyのルーティング 2 Symfonyで知っておくと便利なconfig tagテーブル id name 1 symfony 2 routing post_tagテ
クラウドワークスが、 社外のエンジニアに寿司をおごる企画をやっている というのを見かけて、寿司がタダで食べられるなら良いなと思い、なにも考えずに申し込んでみました。 1 選べる!寿司ランチ この企画は、寿司を食べながら対話するエンジニアを指名できるシステムになっています。筆者は、最近案件で使ったReact+Reduxや、RailsとReactを組み合わせて使うことに興味があったため、また、最近子供が生まれてリモートワーク制度を活用していたということで、そのあたりにも興味があり、 suzan2go さんを指名しました。suzna2goさんは、クラウドワークスの中でも、 Reactの普及にとくに熱心 なエンジニアだそうです。 寿司 こちらがクラウドワークスで提供していただいた寿司になります。 筆者もたまに出前する銀のさらの寿司 ごちそうさまでした。なお、お茶は出なかったので、ハックルベリーさん
SPA の開発において、効率良く作業を進めるためには、ライブリロード1がなんとしても必要です。 たとえば、1.商品選択画面、2.注文画面、3.注文完了画面の3ステップからなるアプリを考えてみましょう。 素朴にReactを使って開発した場合、コードの修正したあと、結果を反映させるためにブラウザをリロードすると、状態がリセットされます。 そのため、最後の注文完了画面の調整をしたいときに、リロード後、毎回商品選択からはじめて、商品を選択し、送付先住所を入力した後、結果を確認しなければなりません。 仮に商品選択画面と注文画面での手動データ入力に1分かかるとすると、注文完了画面を100回修正して、そのたびに結果を確認すると、100分もの無駄な待機時間が発生してしまいます。 アプリの状態を保持したままコードの修正を反映できれば、効率的な開発が可能になります。 実現方法 Reactアプリの開発で、ライブ
「メールクライアントはどれだってひどい。このメールクライアントは、ひどさがマシってだけ」 -- mutt作者 この記事では、muttというコマンドラインのメールクアイアントにnotmuchというメール検索プログラムを組み合わせて、Mac OS X上で、メール送受信環境を構築する方法を説明します。不明点があればコメントでどうぞ。 目次 メールの基礎知識 MxA 関連するプロトコル メールボックス 筆者のメール環境 動機 使用するプログラム mutt notmuch getmail SpamAssassin Razor2 terminal-notifier launchd ssh + sendmail メール受信のシーケンス 1. POP3でメール受信 2. スパム判定 3. 一時フォルダにメールファイルを保存 4. スパム報告&学習 5. メールファイルをメールボックスに移動 6. 検索イン
Alistair Cockburn による Hexagonal architecture の翻訳です。PoEAAで言及されていることから、2002年ごろにはすでにC2 Wikiにページがあった模様。似たようなアーキテクチャである クリーンアーキテクチャ も翻訳したので参考にしてください。 この記事は著者から許可を得て公開しています。Thanks to Alistair Cockburn! 目次 パターン: Ports and Adapters (構造に関するパターン) 意図 動機 解決法の本質 構造 サンプルコード ステージ1: FIT アプリ 定数をモックデータベースとして ステージ2: UI アプリ 定数をモックデータベースとして ステージ3: (FITまたはUI) アプリ モックデータベース 応用ノート 左右の非対称性 ユースケースとアプリケーションの境界 ポートはいくつ? 既知の用
Robert Martin (a.k.a. ボブおじさん) による、 The Clean Architecture の翻訳です。似たようなアーキテクチャである ヘキサゴナルアーキテクチャ も翻訳したので参考にしてください。 この記事を翻訳して公開したことは 8th Light, Inc. に報告済みです。いまのところ苦情は来ていません。 ここ数年以上、システムのアーキテクチャに関する実にさまざまなアイデアを見てきた。これには、次のものが含まれる: Hexagonal Architecture (別名 Ports and Adapters) by Alistair Cockburn。Steve FreemanとNat Pryceが、Growing Object-Oriented Software というすばらしい本で採用した。 Onion Architecture by Jeffrey Pa
Androidアプリプログラミングで、ある程度経験を積んだ開発者なら、Fragmentにまつわる操作で不意に発生するIllegalStateExceptionには、いくどとなく苦しめられたことがあるでしょう。 Fragment は、スマートフォンのためのOSから、タブレットなどより幅広いスクリーンに対応できるマルチデバイスなOSに進化するために、Android 3.0で登場したコンポーネントです。 Fragmentを利用すれば、画面をいくつかの要素に分割して、それぞれをMVCで構築し再利用するという、 Smalltalk-80のMVC的な方法論 が可能になります。 一方、いまでは広く認められていることですが、Fragmentのライフサイクルは よく見てみると複雑 で、足をすくわれがちです。 そこで、 Fragmentに対するカウンターとして、 Square は、FlowとMortarという
目次 問題の根っ子 Web制作の場合 ー インブラウザデザイン(Designing in the Browser) Webアプリ開発の場合 ネイティブアプリの場合 イニシアチブの所在 プログラマーへの指示の出しかた 判断材料を提供する 検索性の高い資料 カラースキーム レスポンシブ対応 インタラクション プラットフォームごとに異なる自然な表現 まとめ アプリ開発においてのフローは、まずデザイナーがデザイン指示書を作成し、プログラマーが、なるべく忠実にそれを再現するように実装していくという順序になることがよくあります。自然で現実的な発想ではあるのですが、実際の開発の過程では、この流れが思っていたほどスムーズにいかないこともあります。そこで、これまでの経験を踏まえて、今後案件をはじめる前にデザイナー、あるいは、プロジェクトマネージャーやディレクターに読んでもらうための資料を作成することにしまし
BowerとMacGlashanによるMVPを提唱した論文の要約です。最近MVPモデルのフレームワークでプログラミングをしているのですが、ビューとプレゼンターの境界が曖昧になって、どちらにコードを置くべきか迷う場面が出てきたので、根本的な理解を求めて読んでみました。 PotelのMVP に比べると、自分が理解しているMVPの姿とほぼ同じだったこともあり参考になりました。ただ、現在モバイル開発やウェブ開発でよく言われているMVCと、この論文で言及されているMVC1はだいぶかけはなれているので、昨今の典型的なMVC(MVPとかなり似ている)とMVPの微妙な違いは、これを読んでもよくわかりませんでした。 TWISTING THE TRIAD The evolution of the Dolphin Smalltalk MVP application framework. Andy Bower,
ディレクターあるいはプロジェクトマネージャーに、こういう点を意識してもらえると助かるという点を開発者の視点から列挙します。ディレクターとプロジェクトマネージャーの違いというのは、わたしにはよくわからないので、本稿では同じものとして扱います。以後は文字数の少ないディレクターで統一します。 なお、わたしは数人規模の小規模受託ソフトウェア開発しか経験がありませんので、この記事もその規模の開発が対象と考えてください。例えば、アプリ開発であれば、iOSプログラマー1人、Androidプログラマー1人、UIデザイナー1人、ディレクター1人といったあたりが、よく見られる構成です。開発期間は、せいぜい数ヶ月〜半年程度です。この程度の小規模開発であれば、実際のところ、多少の問題が起きても、作業者が何日か徹夜作業をすればどうにか丸く納まるということがほとんどです。大規模開発ではこうはいかないと思うので、ソフト
Git Community Book から、1章2節の The Git Object Model を翻訳。ライセンスは、 GPLv2 。 多くのGit解説本と違い、まずGitの内部モデル解説から入るという、おもしろい構成の本です。人によっては、このほうがわかり易いかもしれません。Gitは差分データを管理していると誤解されることがたまにありますが、それは誤りであるということがこれを読めばわかります。 SHA プロジェクトの履歴を表すのに必要な情報は、いずれも、40桁の「オブジェクト名」で参照されるファイルに格納されている。オブジェクト名は、このような形をしている: 6ff87c4664981e4397625791c8ea3bbb5f2279a3 このような40文字の文字列は、Gitのあらゆる場面で見られる。どの場面で出てくるものであれ、その名前は、オブジェクトの内容のSHA1ハッシュを取るこ
目次 Gitとは GitHubとは GitHub Desktopの特徴 セットアップ GitHubでのワークフロー 1.フォークする 2.リポジトリをクローンする 3.ブランチを作成する 4.機能追加あるいはバグ修正をコミットする 5.プッシュする 6.プルリクエストを作成する GitHubでのワークフロー(2回目以降) 1.upstreamから更新を取得する 2.以降 コンフリクトの解消 自分がオーナーまたはコラボレーターに指定されている場合のワークフロー まとめ 更新履歴 本稿では、 GitHub 上で運用されている開発プロジェクトに、公式クライアントである GitHub Desktip を使用して参加する方法を説明します。 本稿は、デザイナーやディレクターなど、プログラマ以外の方を対象とします。 GitHub Desktopを使用すれば、基本的なフローからはずれない限り、コマンドライ
PythonJSというPythonからJavaScriptへのトランスレーターで変換されたコードが、元のCPythonコード1よりも高速になったという 記事が出ました 。ちょっと興味が湧いたので、PythonJSについて調べてみました(この記事はプログラマ向けです)。 PythonJSとは PythonJS は、正確に言うと、Pythonから、JavaScriptを含む各種プログラミング言語(現状、JavaScript,Dart,Lua,CoffeScript)へのトランスレーターです。 このトランスレーター自体はPythonで書かれていますが、empythoned を使ってNode.jsから実行することもできます(empythoned自体もPythonJSに同梱されてます)。Node.js用のライブラリとしてのインターフェイスもありますので、Node.jsアプリケーションから、Pytho
目次 自動セミコロン挿入(Automatic Semilocon Insertion) Restricted Production ASIの害 セミコロンにまつわる論争 で、どっちがいいの? JavaScriptには、 自動セミコロン挿入 という機能があり、行末でセミコロンを省略しても、多くの場合文法的に問題ありません。 しかしながら、 JavaScript: The Good Parts などで指摘されているように、自動セミコロン挿入は有害な機能であるため、JavaScriptのステートメント末尾には必ずセミコロンを付与するというのがフロントエンドエンジニアの共通認識だと思っていました。1 ところが、 Bootstrap に含まれるJavaScriptコードを見てみると、基本的にセミコロンが使用されていません。 調べてみると、どうも世の中にはJavaScriptのステートメント末尾にセミ
次のページ
このページを最初にブックマークしてみませんか?
『blog.tai2.net』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く