この記事は、著者の許可を得て配信しています。 Why programmers don’t write documentation 最近ではずっとコードのドキュメンテーションに関連した記事を書いていたので、当然、私のMediumのおすすめ記事には「開発者がドキュメントを書かない本当の理由」という記事が表示されるようになりました。この記事では、ドキュメントを書くための優れたツールがないことが、ソフトウェアエンジニアが自分の作業や判断をドキュメンテーションする意欲を失わせる最大の原因について書いています。 私は普段、特定の記事を批判したりはしませんが、この記事には怒りを覚えました。このライターは図解ツールについていくつかメリットに関して述べてはいますが、全体的に誤解を招くような内容になっており、この重要な問題をより分かりにくくさせています。2つの図解ツールを比較して、どちらも不十分なツールである

2020年も多くの素晴らしい技術書がたくさん出ました. その中でも（昨今のトレンド・流行りも手伝ってか）Python本の多さ・充実度合いは目立つものがあります. （このエントリーを執筆した12/19時点で）Amazonの本カテゴリで「Python」と検索すると1,000件以上出てきます*1. これだと目的の本にたどり着くだけで疲れそうです. このエントリーでは, 主にPythonを学びたい・現在使っている方 手元の業務を効率化したり, RPAっぽいことをやりたい方 エンジニア・データサイエンティストとして業務や趣味・個人開発をされている方 を対象に, 今そして来年2021年に読んでおきたいPython関連書籍（と抑えておきたいサービス） をエンジニアでありデータサイエンティストである私独自の視点で紹介します*2. なおこのエントリーはこのブログで例年執筆している「Python本まとめ」の2

この記事は、設計・アーキテクチャ Advent Calendar 2018 の第7日目の記事である。 はじめに この記事では、IT業界19年目の僕が実践している変更に強いアーキテクチャについて、出来るだけ難しい表現を避け、教科書的なありきたりな内容ではなく現場の肌感覚に近い切り口で「超ザックリ」な解説を試みてみようと思う。 普段自分がよく用いている実装パターンの紹介ともいうべきかも知れない。 この記事で説明すること いざ「変更に強いアーキテクチャとは」とズバリ訊かれても、一概に「これだ！」という答えはない。 プログラミング言語や、フレームワークによっても条件が異なるし、利用可能な技術や開発チームの特性、業務要件や運用要件の特性によっても様々であるし、インフラや開発プロセスまで含めて考えると考慮すべきことは無限にある。 ここでは主にソフトウェアの構造という観点から、"変更に強い" ということ

Swiftのエラーハンドリングは他のメジャーなプログラミング言語のどれとも異なる新しい仕様を持っています。特に、検査例外を持っているのですが、これはJavaで採用された以降はほとんどの言語で採用されていないため、現代では否定されている過去の間違いだったと広く認識されていると思います。そのため、Swiftユーザーで無い人は、検査例外という言葉をみた瞬間に興味を失ってしまうため、その詳細がなかなか世の中に伝わっていないと感じています。一方、私はこんなSwiftのエラーハンドリングをとても気に入っていて、様々な言語の進化の歴史を踏まえた産まれた最も優れた最先端の仕様だと思っています。この記事ではその考えを説明します。 Javaのエラーハンドリング Javaは検査例外を持っています。これにより、あるメソッドがエラーを送出するかどうかを関数のシグネチャとして静的に表明できます。 // 検査例外の例

6. “CSSはその単純さゆえに、 大規模な実装では管理が難しい。 BIG CSS “CSS, for all its simplicity, is a difficult language to manage in large-scale implementations. ” - MVCSS / Overview https://www.youtube.com/http://watch?mvcss.v=github.R-BX4N8egEc io/ https://www.flickr.com/photos/nickpiggott/5212359135

マネジメント 新しいチームのあり方を探求 就活 就活生必見！サイボウズの疑問 ティール組織 会社の「あたりまえ」が変わる 多様性 100人100通りの個性 ワークスタイル 働き方、生き方、もっと自由に 青野慶久 サイボウズ社長の想いと覚悟 キャリア 人生の「積み上げ方」を見直す 複業 複数の「本業」をもつ働き方 人事制度 多様な働き方を支える仕組み マンガ サクッと手軽に読める！

インフラ系のエンジニアは、あまりリファクタリングとかクラス構造といった視点でコードを読む機会が少なくて、勢い作ったスクリプトやツールはそれはそれはひどいものになりがちです(体験談)。 僕もエンジニアになって以来、まともなコードなんか書いたことなくて、従ってる原則といえば、「グローバル変数は悪」とか「短いことはいいことだ」とか「コメントは書かない方がいい」とか、なんか学生の時にたまたま目にしたよくわからない何かに従ってる程度。 少し大きい規模を書き始めると、昨日の自分と今日の自分で命名規則が全然一貫性なくて、「getHoge()」と「makeFuga()」がおんなじようなことをやってたりしていつも嫌悪感に駆られてました。 ちょうど 1000 行くらいのアプリ書いてたところだったので毎日吐き気をこらえながら「まずは動くものをつくるんだ。全てはそれからだ」と言い聞かせて汚いコードをゲロゲロしてた

「Androidアプリを作っている（作ってもらっている）けど、脆弱性が心配」という声はtwitterでも目にすることがあります。そして、「『安全なウェブサイトの作り方のAndroidアプリ版』があったらいいのに」という希望を目にしたこともあります。 6月13日にIPAから公表された「IPA テクニカルウォッチ『Androidアプリの脆弱性』に関するレポート」は、この『安全なウェブサイトの作り方のAndroidアプリ版』に相当する位置づけのドキュメントです。なぜそう思うかというと、以下の性格が『安全なウェブサイトの作り方』と共通するからです。 Androidアプリの基本的な問題に絞っている 届出の多い脆弱性にフォーカスしている 以下、もう少し詳しく紹介します。 Androidアプリの脆弱性とは何か 同レポートでは、Androidアプリの脆弱性を以下のように定義しています（同書P3）。 ■ 「

viというエディタがある。長い歴史のあるエディタである。ユーザー視点で見ると、コマンドモード・入力モードという二つのモードがあって、モードを切り替えながらテキスト編集するスタイルである。GUI全盛のモードレスなエディタに慣れきってしまった自分には、かなり面食らったエディタであった。初めて起動した時、文字も入力できず、終了の仕方も分からない...。何じゃこれは？ そう思って調べてみると、viには非常に多くのショートカット的コマンドがある。その多さにまず面食らう。とても覚えきれないと。以下は、自分で調べて理解できた使い方である。軽く100以上の操作がある。（これでもなるべく行を節約して書いたのに）しかも、以下の表でもすべてを網羅できている訳ではない。 どうにか、これらのコマンドをなるべく覚えないで、そこそこ使えるようになりたい。何を覚えて、何を覚えなくていいのか、探ってみた。 viエディタの使

エンジニアという職業柄かシェルスクリプトを書くことはちょくちょくあるのですが、自分なりに気を付けていることを備忘録＆自分への戒めも含めて、簡単に書いてみたいと思います。 変数は大文字 シェルスクリプト書いていれば変数の出番は至るところであるでしょう。その際、可読性を増すように、変数は大文字を使っています。 RET=`cmd1`みたいに。好みの問題もあるでしょうが、分かりやすいので。 クオテーションは選ぶ クオテーションにはシングルだったり、ダブルだったり色々ありますが、使い分けておいたほうがよいでしょう。 変数の展開がないようであれば、シングルクオーテーションのほうがスマートでしょうし、展開があるのならダブルクオーテーションを使えばと。 ダブルクオーテーションを使うのにも意味があって、変数は「$RET」のようにクオテーションで囲まなくても動作はたいていするのですが、 echo "${RET

あまり参考にならないと思いますが、私がどのようにして C 言語や Windows プログラミングを習得したのかを書いていこうと思います。 C 言語を勉強しなければならないと思ったのは、中学 1 年生の 4 月でした。多くの中学校、高校にもあると思いますが、私が入学した「高槻中学校・高等学校」にもパソコン部のようなものがあり、そこでは C 言語が流行していました。 C 言語が流行していたといっても、「C 言語が良いらしいぞ」という言葉が流行していたという程度であり、誰か C 言語によるプログラミングがものすごくできて人に教える能力がある程度の生徒や教員がクラブにいた訳ではありません。当時、クラブでは PC で動作するフリーウェアのゲームが多数流行っており、放課後や昼休みなどに皆で必死にゲームをして遊んでいました。そのときに流行っていたゲームの 1 つに、以下の「Flying Jump」という

@IT 向けに書いた記事が公開されました。 フリーズしないアプリケーションの作り方 これもまた、裏ではいろいろと思うところあり。 タイミングよかった いやー、題材が題材だけに、C# 5.0 とか .NET Framework 4.5、VS11 の正式版が出る頃に出そうかなーなどと思って書き貯めてあった文章だったり。 諸事情あって、実は意図せず今月完成させて出すことになって、今日の公開だったわけですが、意図せずいいタイミングになったなぁ。 BUILD での発表内容がもうほんと非同期処理だらけで。「WinRT では50ミリ秒以上かかる処理は非同期APIにします」とか、C# 5.0 の async/await 構文の再説明も多々入っていたり。 ついかっとなってやった。後悔なんてあるわけない。 まあ、非同期処理は一応、年々ホットな話題になってきているので、他にも記事はあるにはあります。 ただ、自分

会社でレガシーコード改善ガイドの読書会をやっていて、次回で読了だ。4月に入ってから週に1回くらいのペースでやっていて、2ヶ月半くらいかかった。途中、ゴールデンウィークや所用で開催しないこともあったので、１０回くらいで完走したことになる。 一人当たり、1章ないし2章くらいを担当して、その章に書いてあることを説明した後にみんなであーだこーだ議論をする。気になったことを質問したり、どうも良く分からないことをみんなで考えたりする。 テストがないコードはレガシーコードだ！というキャッチフレーズはわたしの心をとらえた。 参加者の皆さんとその価値観を共有できた事はうれしい。 現場での開発の実情をいろいろ教えてもらった。テストを書くことはあまり一般的ではないということにわたしは衝撃を覚えたのであるが、この読書会を通じて、テストを書かない開発というのがレガシーコードを作っている事に他ならないという共通の認識

ソフトウェアの開発を行うときに、まずテストケースを先に作ってから機能を作り込む「テスト駆動開発」（Test-Driven Development：TDD）。これにより、ソフトウェアの開発工数や品質にはどの程度の変化があるのでしょうか。 TDD(テスト駆動開発)の適用評価を紹介した研究論文 - エリクソンはじめ3社：森崎修司の「どうやってはかるの？」：ITmedia オルタナティブ・ブログ この疑問について調査した論文を、奈良先端科学技術大学院大学 助教の森崎修司氏が3月10日のブログ「国立大学法人奈良先端科学技術大学院大学 助教」のエントリ「TDD(テスト駆動開発)の適用評価を紹介した研究論文 - エリクソンはじめ3社」で紹介しています。 開発時間はやや増えたがコードの品質は上がった 論文全文は有料なので読めないものの、森崎氏のブログによると次の知見が得られたとのことです。まず、ソフトウェ

会社の勉強会で自分の今までの経験からテストについてお話をした。その資料を公開する。自分が関わった、Oracle8、DEC Rdb、日本語COBOL、そしてSamba3.0国際化プロジェクトでのテストやディリービルドなどについて紹介した。 テストファースト開発など、最近広く知られるようになってきたが、ディリービルドとリグレッションテストの実行という方法論は昔からソフトウェア製品開発の現場では行われていたベストプラクティスである。そのリズムとか雰囲気を伝えたかった。 テスト勉強会よしおか100311 1View more presentations from Hiro Yoshioka. テストがある開発現場ってのは、こんな感じなんだ〜という雰囲気が伝われば幸いだ。 アジャイル開発方法論としてXPの手法とかいろいろ知られているが、このディリービルドとリグレッションテストというプラクティスもその

理数系の頭脳が必要だと思っている プログラマは理数系の仕事。そんな「誤解」したイメージを持っている方がいるかもしれない。もちろん、あえて「文系」か「理系」かと分類するのであれば、理数系になるかもしれない。 しかし、本当に数学の知識が必要になってくるのは、ゲームのプログラムや科学技術計算をするような高度なプログラムが必要になった時だ。PHPやJavaScript、ActionScriptなどでちょっとしたWebのスクリプトを作りたいといった程度であれば、必ずしも数学の知識は必要ない。 それよりも大切なのは、正しい単語（ファンクションやパラメータ）を、正しい文法で並べてスクリプトを作る能力だ。つまりは、伝えたいことをコンピュータに正しく伝えて、会話をする能力といえるだろう。そういう意味では「文系」であるといってもよいかもしれない。というよりは、文系か理系かなどはあまり関係なく、ちょっとしたきっ