Python のコーディング規約 PEP8 に準拠する - Qiita
この Qiita の連載記事ではデータ分析のための主要言語として Python を利用してきました。ところでみなさんは Python のコーディング規約 PEP8 をご存知でしょうか。 ソースコードスタイルガイド PEP8 ソースコードは一般に「書かれる時間」よりも「読まれる時間」の方が長い、そのような事実に基づいて、「スタイルを統一し読みやすいコードを書こう」というアイデアのもとに作られたのがこのガイドです。 Style Guide for Python Code http://legacy.python.org/dev/peps/pep-0008/ 本家は当然ながら英語ですが有志の方が日本語に翻訳してくださっています。 PEP8 日本語訳 https://github.com/mumumu/pep8-ja どちらにせよ Python を利用する方は必ず一読するべきかと思います。 自動的
シェルスクリプトを書くときはset -euしておく - Qiita
を書いておく。以下解説。 set -e エラーがあったらシェルスクリプトをそこで打ち止めにしてくれる（exit 0以外が返るものがあったら止まるようになる）。「あっあれここでうまくいってないからデータ準備できてないのにあれあれっもうやめて！」ってなるのを防げる。 set -u 未定義の変数を使おうとしたときに打ち止めにしてくれる。Perlでいうuse strict 'vars';的なもの。 って気軽な気持ちで書いてしまって、「ん、やたら時間かかると思ったらスペルミスうわなにをするやめ」ってなるのを防げる。 一部だけ例外にしたい はてなブックマークのコメントより -e は command1 || command2 みたいなことが出来なくなるの使うことないな。-uは付けといて良いが。 確かにおっしゃるとおりですね。コマンドの失敗を考慮して書いている部分については（もしくはやたらexit 0以外
オブジェクト指向は禁止するべき - きしだのHatena
プログラムがまだ不慣れな人が「プログラムちょっとわかるようになったけど、まだぜんぜんオブジェクト指向とかできてません」のように言ったり、ちょっと慣れた人が「このソース、ぜんぜんだめ。オブジェクト指向ができてない」にようなことを言ったり、まるで、オブジェクト指向ができてるかどうかがよいプログラムかどうかを表すことになってるようだ。 Javaのアルゴリズムの本に、「Javaなのにオブジェクト指向ができていない」のような書評がついているのを見たときには、お前は何を求めてるんだと思ったりもした。 そのようなオブジェクト指向は、窓から投げ捨てるべきだ。オブジェクト指向はプログラムのよしあしの基準にならない。 むだにHogeインタフェースとHogeImplクラスがあったり、むだにnewするだけのcreateメソッドがあったり、どこで値が設定されてるかわからないオブジェクトがひきまわされてたり、ソースコ
Pythonコードのプロファイリング - shkh's blog
普段、Pythonのコードは何となく速かろうという、言ってみれば勘で書いているのだけど、その勘とやらは往々にしてウンコードを生むものである。そこで、プロファイラを使っていきたいと思う。 使えそうなツール そういうわけで、いくつか使えそうなツールをリストアップした。 経過時間のプロファイラ ツール名 メモ profile ビルトイン, ピュアPythonの決定論的プロファイラ cProfile ビルトイン, C拡張の決定論的プロファイラ line_profiler 行単位の決定論的プロファイラ Plop 統計的プロファイラ, Dropboxの人が作ってる statprof 統計的プロファイラ, 開発停止？ yep 拡張モジュール用の統計的プロファイラ, バックエンドにgoogle-perftools メモリのプロファイラ ツール名 メモ memory_profiler 行単位でメモリ消費量の
プログラマー向け最強フォント「M+」 | ソフトアンテナ
プログラミングに最適なフォントは何でしょうか。海外のブログ記事「The Best Font for Programming: M+」にて、プログラマー向けのベストフォントとして「M+」フォントが推奨されていました(Reddit)。 ブログによるとRetinaディスプレイのような高詳細ディスプレイで使うのに具合がよく(低解像度ではTerminusフォントが推薦されています)、0(ゼロ)とO(大文字のO)のような紛らわしい文字がはっきり区別できる点がお気に入りポイントの様子。 ↑このように。 実は、M+フォントは日本人が開発している日本語対応のフリーフォントです。海外発のフォントの場合アルファベットの見栄えはよくても日本語と合わせるとどうも…といったことが起こりがちですが、M+フォントだとそのような心配は不要だと思います。日本人開発者なら使わない手はないかもしれません。 M+フォントは、個人利
「コード汚くてもデザインが見えればいいじゃん」への返答
なぜコードが綺麗じゃないといけないの？という質問をごく一部の方、特にデザイナーさんから受けることがあるので（半分くらいの人はネタで言ってますが）、自分なりの意見をまとめたいと思う。勉強不足で浅い感あるので、偉い人にご指摘いただけると嬉しいです。 「コード汚くてもデザインが見えればいいじゃん」の定義について 「コード汚くてもデザインが見えればいいじゃん」はかなりふわっとした印象を持つので、ここでは「コードが汚い」の定義として、以下の2つを挙げる。 メンテナンス性に欠ける （W3Cの）仕様に沿っていない なので「コード汚くてもデザインが見えればいいじゃん」というのを「メンテナンス性に欠け、仕様に沿っていなくても、デザインが見えていればいいじゃん」という意味に置き換えて話を進める。 確かに表面的な視点で見ると、エンドユーザーには関係がなさそうに見えるかもしれない。 例えばメンテナンス性の高いコー
パーフェクトPython - forest book
Python3 に特化した専門書という位置付けですが、(Python3 に関した) 言語仕様やその変更、ライブラリの詳細の違いなどを除けば、Python2 でも活用できる知識が大半です。まだ Python2 しか使っていないという方でも十分に役立つ内容だと思います。 ただ、本書を読み進める上で1つだけ忘れてはいけないことがあります。Python 全般について丁寧に解説されていますが 著者名が Python サポーターズとなっていますが、ついったーなんかでは Python モヒカンズなんて言われています。 パーフェクト Python の執筆に参加しました — プログラマのネタ帳 二冊目 と何だかこわい人たちが書いた本だということです。まずはそのことを念頭におくことで本書を楽しんで読み進められる心の準備が整った、言い換えると、覚悟はできたと言えます。そうすれば、途中でこわくなってきても勇気をも
「新入社員のための大規模ゲーム開発入門 サーバサイド編」のスライドを公開しました｜技術ブログ｜北海道札幌市・宮城県仙台市のVR・ゲーム・システム開発 インフィニットループ
「新入社員のための大規模ゲーム開発入門 サーバサイド編」のスライドを公開しました matsuiです。 先週末の2014年6月13日～14日に、札幌でオープンソースカンファレンス 2014 Hokkaidoが行われました。 弊社インフィニットループもスポンサーとして、セミナーの発表を1コマと、ブースを出させていただきました。 その際に使用したスライド資料を公開しましたので、どうぞご覧下さい。 http://www.slideshare.net/infinite_loop/ss-35901898 おかげさまで満席でした。来て頂いた方ありがとうございます。 講師の佐々木、なぜか白衣です（理科の先生に憧れてるらしい）。 ブースはこのような感じです。 新作ゲームである「勇者と1000の魔王」と、Android用のタイムカードアプリである「かざしてシュキーン」を展示しました。 ツイート
プロとしての行為 Act as Proffesional
食事を抜く、おざなりにする 朝食、昼食、夕食を熱中しすぎて抜いてしまう。ブドウ糖は蓄えておくことができません。定期的に栄養を取らないと脳がエネルギー不足となって、生産性の低下を招きます。凡ミスが多くなってくる。 きりの良いところで必ず食事をとること。食事の間隔があきすぎることがないように注意する。 生産性のないことに2〜3時間熱くなる 落ちついてコードを読み、設定を直せばすぐに解決するバグを、憶測で○○が悪いのかな？とあれもこれもと手を出すうちに2，3時間を費やしてしまい疲弊してしまう。 感情を抑え、物事を論理的に考える落ち着きを取り戻そう。 何を完了したら仕事が終わりなのかを理解していない コードを書けば仕事は終わりですか？QAやテストやドキュメントなどはいりませんか？誰に承認をえるのですか？これら、仕事として必要なことに注意を向けずに仕事を終わったと思ってしまう。本当に足りないことはあ
これはマネしたい！スーパーエンジニア達の習慣 | Act as Professional
いままで勉強会に顔を出し、すばらしいエンジニアと数多く会うことができた。そして、スーパーエンジニアと共に仕事をすることもできたし、できている。そんなスーパーエンジニア達が持っていた習慣を僕の経験と視点からまとめてみる。 自分が使う道具を厳選して選んで手入れをしている エンジニアでいえばエディタやツールなど。皆が使っているIDEやエディタを何も考えずに使い始めたりしない。 厳選したエディタやツールを使って、手になじませるのである。手になじませるというのは、2つの意味がある。 1つは操作性に慣れること。呼吸をするように自然に、キーボードの上を駆け回る心地よいリズムを奏でるエディタを選ぶ。 2つめは、自分に合わせて拡張しているということ。プラグインのON/OFFだけではなく、オリジナルのショートカットを設定し、適切なハイライト、シンタックスのチェック、コーディングルールのチェック、様々な言語への
ペアプログラミングして気がついた新人プログラマの成長を阻害する悪習
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 最近、あまりプログラミングが得意でない人のサポートをする形で、長い時間にわたってペアプログラミングを行っている。そのなかで、気がついた悪い習慣と成長するための良い習慣というものをまとめてみる。 この記事のバックグラウンドとなる体系的知識が本になりました。 エンジニアリング組織論への招待 ～不確実性に向き合う思考と組織のリファクタリング あわせて読みたい 経営者マインドが足りない！vs. 現場に任せてくれない！の対立をなくすカードゲームをつくった話 新人プログラマに知ってもらいたいメソッドを読みやすく維持するいくつかの原則 新人プログラマ
またrebuild.fmがJavaの悪口で盛り上がってたよ
http://rebuild.fm/44/ Androidアプリ作ろうとしてJavaプログラマ募集したらクズしかこなかった全部クズだったとか、ひどくありません? まあそれは置いといて、UIみたいに最初から仕様を決められなくて何度も作り直すようなコードはJavaは不向きみたいな話もまったく同意できないわ。 JavaじゃなくてC#だけど、昨日コードを書いていて string url = "http://www…"; のように、URLを文字列で持っていたけど、やっぱアドレス用のクラスでもったほうが安心だなって思って URI url = new URI("http://www…"); と書き直しました。 当然、このurlを参照しているところは全部エラーになります。 Javaをはじめとする静的型の言語をけなしてる人たちは、これが面倒だと思うんでしょうか。 逆にエラーの出ている箇所を片っ端から直してエ
使いやすいシェルスクリプトを書く
できればシェルスクリプトなんて書きたくないんだけど，まだまだ書く機会は多い．シェル芸やワンライナーのような凝ったことではなく，他のひとが使いやすいシェルスクリプトを書くために自分が実践していることをまとめておく． ヘルプメッセージ 書いてるシェルスクリプトが使い捨てではなく何度も使うものである場合は，本体を書き始める前に，そのスクリプトの使い方を表示するusage関数を書いてしまう． これを書いておくと，後々チームへ共有がしやすくなる．とりあえずusage見てくださいと言える．また，あらかじめ書くことで，単なるシェルスクリプトであっても自分の中で動作を整理してから書き始めることができる．関数として書くのは，usageを表示してあげるとよい場面がいくつかあり，使い回すことができるため． 以下のように書く． function usage { cat <<EOF $(basename ${0})
個人のリポジトリレベルの開発の話をしよう - ローファイ日記
最近、個人のリポジトリレベルの開発でも、自分のためのIssueを立て、自分しか見ないPull Requestを作ったりしている。 docker-registry をインストールするぞ〜 · Issue #1 · udzura/docker-playroom · GitHub Install Ruby recipe by udzura · Pull Request #3 · udzura/docker-playroom · GitHub First version of ikachan module by udzura · Pull Request #1 · udzura/ikachan-node · GitHub この際気を付けていることとして： Issue、最初のdescriptionは最初のTODOへのポインタだけ書いておく プルリクエストは 生煮え の状態で出す 思ったこと、詰まった
「実装をテストする」とは？ - ふぃーるどのーつ
TDD界隈の議論で、「仕様のテスト」「実装のテスト」という話を聞くことがあります。 TDDのよくわからない言葉をどうやって説明するか悩んでいるという話 #SWTestAdvent — うさぎ組 明日からTDDをやってみよう！ - 部屋とアジャイルと私（仮称） 今日のTDD界隈で「仕様のテスト」「実装のテスト」という言い回しを一番よくしているのは私だと思うのですが、勉強会の場などでは話をすることはあるものの、こういう形で残してこなかったので、自分の考えをまとめたいと思います。 公開されているインターフェースの仕様を満たせるなら、API(「リファクタリング」で言う「公布済みインターフェース」)のエントリポイントの内側のクラス設計をどのように組み立てるかは、実装者の裁量に任されているはずです。 品質保証の観点からは、APIの仕様を満たせるテストケースを記述すれば、ソースコードに対してのある程度の
TDDをめぐる、最近の議論についての私見。 - ふぃーるどのーつ
はじめに DHH氏のTDD is dead. Long live testing. (DHH)のエントリは、国内でもさまざまな議論を呼び起こしました。ですが、そのセンセーショナルな見出しの影響もあり、「(TDDと同一視した上での)ユニットテストは不要」などの、ミスリードされた論調も見られます。乗り遅れた感もあるのですが、前述のエントリに限らず、TDDについて最近考えていることをまとめたいと思います。 TDD＝テストファーストではない ケントベックの「テスト駆動開発入門」や、Uncle BobのTDD三原則の影響もあり、TDDでは、まずテストファーストするのだ、という印象をお持ちの方がいると感じてるのですが、いきなりテストファーストするというのは、教条主義なところがあり、現場に適用するのは敷居が高いのは確かです。 TDDを実践する上で大事なのは、テストによって開発が駆動されることです。すなわ
毎日コードを書くこと - snowlongの日記
ワザノバで紹介されていたKhan AcademyのJohn Resigが投稿した Write Code Every Dayの翻訳です。 訳がおかしいなどの指摘をいただけると大変助かります。 去年の秋、自分のプロジェクトのコーディングを始めたんだけど、あまり進捗がよくなくてKhan Academyの仕事の効率を犠牲にすることなしに作業をすすめる方法を見つけらずにいた。 自分のプロジェクトへの取り組み方にはいくつかの問題を抱えていた。 私は週末にプロジェクトに取り組むことを優先し、平日の夜は時々といった具合だった。 自分にとってはその戦略は効果的ではなかったことが今ではわかっている。 週末の間も仕事と同じくらいの高いクオリティでプロジェクトに取り掛かり完成させるという作業は信じられないほどのストレスだった。（そして、うまく行かなかったら失敗したような気分だった。） 週末にいつも予定が空いている
プログラマーを悩ませる、命名の難しさについて
話の発端は 先日公開された FC2 ソースへの感想から。 http://opensource.slashdot.jp/story/14/03/24/0937246/FC2%E3%83%96%E3%83%AD%E3%82%B0%E3%81%AE%E3%82%BD%E3%83%BC%E3%82%B9%E3%82%B3%E3%83%BC%E3%83%89%E3%81%8C%E3%82%AA%E3%83%BC%E3%83%97%E3%83%B3%E3%82%BD%E3%83%BC%E3%82%B9%E5%8C%96%E3%81%95%E3%82%8C%E3%82%8B isExistメソッドとか (スコア:1) by Anonymous Coward on 2014年03月25日 10時54分 (#2568810) もろに日本人っぽいソースコードで好感が持てる。
ポインタ宣言の*記号、左寄せ派? 右寄せ派?
C/C++でポインタ変数を宣言するときの*記号をint* a;のように左寄せで書くか、int *a;のように右寄せで書くか。 右寄せで書く場合、「Cでは宣言と使用の文法を一致させる」という規則から考えれば素直に解釈できるという話。
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
JONITOGEL < Tips Slot Gacor > Menang Setiap Hari