サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
画力アップ
www.kaitoy.xyz
Bash on WindowsでWindows側からUbuntu側のファイルをいじると危険という情報を見つけたので、試してみたら確かに困った状態になった話。 Bash on Windowsとは Bash on Windows (aka BoW)は、2016/8/3に公開されたWindows 10 Anniversary Updateで使えるようになった、Windows上でBashが使えるようになる機能。 POSIX APIのWindows実装を提供するCygwinなどとは違い、WindowsのサブシステムとしてUbuntuが動き、その上でBashが動き、そこからUbuntu用のバイナリをそのまま利用できるというもの。 2016/11/17現在でまだベータ版の機能。 Windows側からUbuntu側のファイルをいじると壊れる問題 Microsoftの中の人のブログに、BoWがセットアップさ
この記事を読んだ、またはGitのオブジェクトモデルを理解していることを前提に、Gitの git checkout というコマンドについて説明する。 このコマンドは普通ブランチを切り替えるものと説明されるが、主たる機能は オブジェクト格納領域から指定されたファイルを取り出し、ワーキングディレクトリに配置する ものである。 つまりこれがGitにおけるチェックアウトで、チェックアウト=ブランチの切り替えではない。 コマンドに与える引数によっては HEAD の付け替え、つまりはブランチの切り替えもする、というだけ。 git checkout の動作を HEAD の付け替えの有無によって分けて考えると分かりやすく覚えやすいので、以下そのように説明する。 HEADを付け替えないgit checkout HEAD を付け替えない git checkout は、引数にワーキングディレクトリ内の ファイルま
Kaitoy's Personal Tech Blog
Gitの良さがいまだに分からないという人がいるようなので、Git派の一人としてSubversion(以下SVN)と比較してのGitの良さ(メリット)について語りたい。 (GitとSVNの違いについては他の人の記事に詳しいのであまり書いていない一方、勢い余ってGitのデメリットも書いた。) 本題に入る前に、冒頭にリンクを貼った記事についてひとつだけつっこんでおく。 つっこみどころは他にも沢山あるけど。 ※話の前提としてgitとSVNを採用している現場に下記のような割と違いがあるとする。 git イシューごとにブランチを切り、ローカルでコミットして、リモートブランチにpushして、GitHub・GitLab・Bitbucket経由でマージリクエスト。コードレビューの後にマージ。 SVN リモートのtrunkに個々人が直接コミット。コードレビューはあまりない。ブランチを切ることもない。 このよう
最近GitHub PagesがHTTPSに正式対応したというニュースを見たことをきっかけに、このブログをCloudflareで常時HTTPS化した話。 このブログ このブログはGitHub Pagesでホストされている。 GitHub Pages上のWebサイトはデフォルトでは<GitHubユーザ名>.github.ioというドメインで公開されるが、ちょっとかっこつけたかったのでカスタムドメイン(www.kaitoy.xyz)にした。 GitHub Pagesは2014年3月から非公式にHTTPSをサポートしていて、2016年6月8日に正式サポートを表明したが、これは<GitHubユーザ名>.github.ioドメインだけが対象であり、カスタムドメインはHTTPSサポートされていない。 (2018/5/3追記: 2018/5/1にGitHub PagesのカスタムドメインのHTTPSサポー
今日、よりシンプルにGitHub Pagesを使えるようになったというアナウンスがあり、ソース設定という新機能が追加されていたので、さっそく試してみた話。 GitHub Pagesの新機能: ソース設定 GitHub PagesにはUser Pages、Organization Pages、Project Pagesの三種類があるが、ソース設定が使えるのはProject Pages、つまりGitHubリポジトリごとに使えてusername.github.io/projectnameのようなURLのやつだけ。 今まではProject Pagesで公開するサイトのソースはgh-pagesという名のブランチに置く必要があったが、ソース設定によりmasterブランチのルートに置いたりmasterブランチの/docsフォルダに置いたりもできるようになった。 ソース設定の使い道 Pcap4Jのホームペ
人は生まれながらにして貴賤の別なく、ただオープンソースプロジェクトを勤めて物事をよく知る者が貴人となるなり。 昔、偉い人がそんな感じのことを言っていたような。 私がGitHubで開発しているライブラリ、Pcap4J のスターの数がつい先日 200 に達したのを記念して、これまでどんな活動をしてきたか、この活動によって何を得たかなどについて書きたい。 願わくは、この記事に触発されてオープンソースプロジェクトを始める人のあらんことを。 Pcap4Jとは? Pcap4Jは、パケットキャプチャとパケット解析をするJavaのライブラリ。 ニッチ。 ただ最近になってビッグデータ解析技術が発達し、大量のパケットをリアルタイムで解析してシステムや運用にフィードバックするというのが現実的になってきたので、パケットキャプチャへの注目が高まってきている雰囲気がある。 こういう分野ではJavaがまだかなり人気なの
7/28にDocker for Winodws(とDocker for Mac)の正式版リリースのアナウンスがあったので試してみたけど、期待していたものと違ったしなんだか上手く動かなかった話。 Docker for Windowsとは Docker for WindowsはDocker Toolboxの後継製品。(多分。) Docker ToolboxはWindowsやMacでDockerを使うための製品で、以下のコンポーネントからなる。 Docker Engine コンテナランタイム。 Docker Compose 複数のコンテナを組み合わせたアプリケーション/サービスの構築/管理ツール。 Docker Machine Docker仮想ホストのプロビジョニング/管理ツール。 Kitematic Dockerコンテナを管理するGUIを提供する製品。 Docker Machineと連携してロ
このエントリでは、Yegor Bugayenkoによる記事、Seven Deadly Sins of a Software Projectを紹介する。 (Yegorから和訳と転載の許可は得た。) 以下はその全文の和訳だが、意訳超訳が混じっているので、もとのニュアンスを知りたければ元記事を読んでもいいし、読まなくてもいい。 保守性は近代ソフトウェア開発において最も重要な美徳だ。 保守性は基本的に、新規開発者が本格的な修正を始める前に必要な学習時間で測ることができる。 学習時間が長いほど保守性は低い。 必要な学習時間が無限に近いプロジェクトもあるが、これは文字通り保守不能だ。 私はソフトウェアを保守不能にする7つの基本的で致命的な罪があると考えている。 それらについてここに書く。 アンチパターン 不幸にも、我々が使っているプログラミング言語は柔軟すぎる。 可能なことが多過ぎ、禁止されていること
このエントリでは、Yegor Bugayenkoによる記事、What Does a Software Architect Do?を紹介する。 (Yegorから和訳と転載の許可は得た。) 以下はその全文の和訳だが、意訳超訳が混じっているので、もとのニュアンスを知りたければ元記事を読んでもいいし、読まなくてもいい。 君のプロジェクトにはソフトウェアアーキテクトが居るだろうか? 必要だと思う? まあ、ほとんどのアジャイルチームはそのような役割を明確には定義せず、民主的な感じで働く。 全ての重要な技術的な意思決定はチーム全体で議論され、最多数の投票を得た解決策が採用される。 しばらくして、このようなチームが「ソフトウェアアーキテクト」バッジを誰かのTシャツに付ける事に決めたときは、もっとも評判のいいプログラマがそのバッジを手にする。 このバッジが彼の責務を変えることはまれだけども。 結局、チームは
このエントリでは、Gitが提供するマージのための機能の内、主なもの4つ、真のマージ、リベース、ファストフォワードマージ、チェリーピック について図解する。 ここでマージとは、とあるブランチのコミットが入れた修正を別のブランチに取り込むこととする。 この記事を事前に読んでGitのオブジェクトモデルを理解しておくと分かりやすいかもしれない。 ここで説明するマージは全てローカルリポジトリ内のブランチを操作対象とする。 真のマージ 真のマージは、複数のブランチでそれぞれ開発が進んでいて、つまりそれぞれのコミットグラフが伸びている場合に、それらの修正を統合するときに実行する。 マージするブランチはいくつでも指定できる。 基本的なコマンドはgit merge <ブランチ(複数可)>。 操作に成功すると、マージ後のプロジェクトの状態を表すコミット(マージコミット)が作られ、カレントブランチの先頭に追加さ
このエントリでは、Gitの基本的な使い方は理解している前提で、そのリポジトリの構造をなるべく正確に説明する。 ここに書いてあることは概ね、筆者がO’Reillyの蝙蝠本を読んで得た知識に基づく。 リポジトリの構造というとコアで上級者向けの知識のように聞こえるが、これをまず理解しておくことで強力で複雑なGitの機能を習得するのが非常に楽になる。 具体的には、Gitにおけるブランチの概念などの理解が深まったり、git resetなどのGit特有で分かり辛いコマンドを自信をもって使えるようになったり、なにより、Gitを使う上での最大のハードルである インデックス や HEAD の概念を完璧に理解できるというメリットがある。 チュートリアルを終えたくらいの初心者にこそ読んでほしいエントリである。 Gitリポジトリの中身 Gitのリポジトリは、プロジェクトをクローンしたときとかにできる.gitディレ
このブログはAtomというGitHubが開発したテキストエディタを使って書いている。 このエントリは、そのAtomのパッケージを作ってみたというお話。 Atomとは Atomは、2015/6/25にバージョン1.0がリリースされたばかりの新しいテキストエディタで、そのせいもあってか日本語サポートはあまり充実していない。 例えば、テキストを画面の端で折り返す「Soft Wrap」という機能はマルチバイト文字に対応しておらず、日本語で横に長い文を書いたりすると画面からはみ出てしまって不便。 しかしAtomは、パッケージなる、機能を拡張できるプラグインみたいな仕組みを持っていて、例えば上記Soft Wrapの問題はjapanese-wrapというパッケージをインストールすることで解決できる。 パッケージは誰でも作って配布することができる。 日本語のワード境界 Atomでブログを書いていて不満を感
このエントリでは、Yegor Bugayenkoによる記事、Continuous Integration is Deadを紹介する。 (Yegorから和訳と転載の許可は得た。) 以下はその全文の和訳だが、意訳超訳が混じっているので、もとのニュアンスを知りたければ元記事を読んでもいいし、読まなくてもいい。 数日前、「なぜ継続的インテグレーションは機能しないのか」という私の記事がDevOps.comに公開された。 それとほぼ同じ日に、Twitterで非常に否定的な批評が送られてきた。 継続的インテグレーションが機能しないとはどういうことだ。この人気なすばらしいアイデアが。 その求めてもない質問への返事をここに書く。 私はこの分野に関して多少の経験があるが、それに基いた論拠は挙げない。 代わりにロジックだけを頼りにする。 ところで、私には50以上のオープンソースや営利プロジェクトで5年間Apac
このエントリでは、Yegor Bugayenkoによる記事、Seven Virtues of a Good Objectを紹介する。 (Yegorから和訳と転載の許可は得た。) 以下はその全文の和訳だが、意訳超訳が混じっているので、もとのニュアンスを知りたければ元記事を読んでもいいし、読まなくてもいい。 Martin Fowler曰く、 ライブラリは本質的には呼び出し可能な関数の集合で、最近は普通クラス内にまとめられる。 クラス内にまとめられた関数? 失礼を承知で言わせてもらうが、これは間違っている。 そして、これはオブジェクト指向プログラミングにおいて、クラスに対する非常に一般的な誤解だ。 クラスは関数をまとめるものではないし、オブジェクトはデータ構造体ではない。 では、なにが適切なオブジェクトなのか? どれが不適切なオブジェクトなのか? その違いは何か? これは論争を呼ぶ主題ではあるが
このエントリでは、Yegor Bugayenkoによる記事、OOP Alternative to Utility Classesを紹介する。 (Yegorから和訳と転載の許可は得た。) 以下はその全文の和訳だが、意訳超訳が混じっているので、もとのニュアンスを知りたければ元記事を読んでもいいし、読まなくてもいい。 ユーティリティクラス(またはヘルパークラス)は、スタティックメソッドだけを持っていて、状態を内包しない「構造体」だ。 Apache CommonsのStringUtils、IOUtils、FileUtilsや、GuavaのIterables、Iterators、またJDK7のFilesはユーティリティクラスのいい例だ。 ユーティリティクラスはよく使われる共通機能を提供するので、この設計手法はJava(やC#、Rubyなど)の世界でとても人気だ。 要するに我々は、DRY原則に従い、重
GitHub Pagesでブログ立ち上げ - Jekyllのためのツールの続き。 前回は、GitHub Pagesで公開するブログサイトを構築するのに、JekyllとJekyll関連ツールを使おうと四苦八苦したが、結局Jekyllに見切りをつけ、Hugoを使うことに決めた。 Hugoとは Hugoは、国内では2014年末くらいから盛り上がってきているブログサイト構築ツール。 そのホームページによると、ウェブサイトフレームワークで、静的サイトジェネレータとのこと。 フレームワークと名乗ってはいるが、その正体は、Markdownで書かれた記事を元にブログサイトのソースを生成するコンテントビルド機能と、記事作成(など)を支援するユーティリティ機能を持ったコマンドラインツール。 また、静的サイトジェネレータというのは、静的なサイトを生成するという意味ではなく、静的にサイトを生成するという意味。もっ
このエントリでは、Yegor Bugayenkoによる記事、ORM Is an Offensive Anti-Patternを紹介する。 (Yegorから和訳と転載の許可は得た。) 以下はその全文の和訳だが、意訳超訳が混じっているので、もとのニュアンスを知りたければ元記事を読んでもいいし、読まなくてもいい。 結論から言えば、ORMはオブジェクト指向プログラミングの原則の全てに違反するひどいアンチパターンだ。オブジェクトをバラバラに引き裂き、もの言わぬ受身なデータ入れに変えてしまう。 小さいWebアプリケーションから、数千のテーブルをCRUD操作するエンタープライズシステムまで、どんなアプリケーションにもORMが存在することはゆるせない。 代わりになるものは? SQLを話すオブジェクトだ。 ORMの仕組み オブジェクト関係マッピング (Object-relatinal mapping、ORM
このエントリでは、Yegor Bugayenkoによる記事、Daily Stand-Up Meetings Are a Good Tool for a Bad Managerを紹介する。 (Yegorから和訳と転載の許可は得た。) 以下はその全文の和訳だが、意訳超訳が混じっているので、もとのニュアンスを知りたければ元記事を読んでもいいし、読まなくてもいい。 スタンドアップミーティング (または単純にスタンドアップ)は、「チームマネージャに状況報告をするためのデイリーチームミーティング」であるとWikipediaに書かれている。 こうしたミーティングは、ソフトウェア開発チームの間でとても人気な手法ではあるが、単なる悪であり、よいマネージャは決してやらない。 以下、その理由を説明する。 私は、スタンドアップのやり方が適切だったり不適切だったりする、と言いたいわけではない。それについて述べた記事
このエントリでは、Yegor Bugayenkoによる記事、Why NULL is Bad?を紹介する。 (Yegorから和訳と転載の許可は得た。) 以下はその全文の和訳だが、意訳超訳が混じっているので、もとのニュアンスを知りたければ元記事を読んでもいいし、読まなくてもいい。 JavaでNULLを使う単純な例を以下に示す。 public Employee getByName(String name) { int id = database.find(name); if (id == 0) { return null; } return new Employee(id); } このメソッドの何が間違っているのか? オブジェクトの代わりにNULLを返す可能性がある、というのが間違っているところだ。 NULLはオブジェクト指向パラダイムにおけるひどい慣習で、全力で避けるべきものだ。 これについて
このエントリでは、Yegor Bugayenkoによる記事、Getters/Setters. Evil. Period.を紹介する。 (Yegorから和訳と転載の許可は得た。) 以下はその全文の和訳だが、意訳超訳が混じっているので、もとのニュアンスを知りたければ元記事を読んでもいいし、読まなくてもいい。 2003年にAllen Holubが書いたWhy getter and setter methods are evilという有名な記事に端を発する古い議論がある。それは、getter/setterはアンチパターンで避けるべきものなのか、 もしくはオブジェクト指向プログラミングに必須なものなのかというもの。 この議論に少しだけ私の意見を加えたいと思う。 上記記事の要旨はこうだ。 getterやsetterはひどい慣習で、これらを使うやつらはゆるせん。誤解の無いようもう一度言うが、 私はget
このページを最初にブックマークしてみませんか?
『To Be Decided』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く