pythonで小さなツールを作る時のtips - Qiita
自分で小さいツールを作る時に心に留めているtipsです． 書き始めたときは「どうせ書捨てだし」と思って書き始めると意外と長い間，もしくはいろんなところで使うことになったりするので，気をつけておくと後から楽になるというような小技です．大規模なソフトウェアの開発ではまた違った流儀があると思います． メインルーチンを関数にする 関数名はなんでもいいのですが，自分は趣味で main() という名前の関数を用意し，メインルーチンは全てそこに書くようにしています． #!/usr/bin/env python def main(): print('hello, hello, hello!') if __name__ == '__main__': main() pythonの小さなサンプルコードを見たりすると関数外の部分にベタで実行コードが書かれていたりします．もちろんそれでも動くのですが，以下の2点で後
「JavaScript初級者のためのコーディングガイド」に補足を試みる - Qiita
はじめに http://qiita.com/raccy/items/bf590d3c10c3f1a2846b を見ていたら、はてブに「理由がないから」ということがよく挙がっていたので、理由をつけてあげたら有益な内容になるかな？と思い、拙いながらも補足を試みようと思います。 【2017 1/3 15:10 追記】 元記事の前提はgulpなどを使ってminifyなども行なえる（もしくは行う目標がある）前提の様子なので、中級者以上がターゲットかなーと思いました。そのつもりで読むととてもいい記事だと思っています。 「最新のJSの書き方を覚えてあとは変換機能に任せればレガシーなJSのキツイところに向き合わなくて済みますよ？」みたいなイメージだとわかりやすいかな？ ==、!= 理由 暗黙の型変換が発生して、別の型の比較が真で扱われてしまう場合があるため。 解説 サンプルコードにも出ていますが言葉足らず
Ruby の yield って結局なんなの？ - YNote
yield って、いまいち分かりにくいですよね。。 わからない⇒調べる⇒忘れる⇒調べる⇒忘れる⇒… のエンドレスループから抜け出すために、自分なりにまとめることにしました。 ブロック いきなり yield じゃないやん！という感じですが、我慢して見てみてください。 …じ・つ・は、Ruby のメソッドはすべて「ブロック」を引数にすることができます。 最近知りました(；ω；)。 def hogehoge( x ) return x + 2 end p hogehoge( 3 ) p hogehoge( 5 ){ p "foo" } ブロックってのは、{ p "foo" } みたいに "{" と "}" に囲まれたやつね。"do" 〜 "end" でもいいみたいだけど。 これを実行すると、 5 7 となります。{ p "foo" } はまるっきりシカトです。 (・∀・) …が、以下のようにすると
「誰がこんなネーミングにしたんだ……。」プログラミングのネーミングルールを決める時に参考にしたい情報まとめ
サイトのメンテナンスにおいてしばしばネックになるのは、どんなネーミング・構成で制御しているのか分からなくなってしまうことです。しっかりと基準に則った、誰がいつ見てもわかりやすいネーミングでコーディングしていくことは、非常に重要なことです。 今回は、プログラマーがネーミングを考える際に参考にしたいサイトを選んでご紹介いたします。 1. codic - プログラマーのためのネーミング辞書 https://codic.jp/ 様々なサイトに紹介され、「ネーミング」で検索しても上位に表示される素晴らしいツールです。例えば、Webサイトの背景に動画を設置する際に、class名をどうしようか悩んだとします。そこでcodicに「背景動画」と入力すれば「background_videos」と提案してくれます。提案されたネーミング以外にも、その他の候補も出てきます。 考える労力を省くことができるという点で優
R言語徹底解説を読む (1) ようこそRプログラミング - 僕らはRを愛しすぎてる
この記事が想定する読者層 もしあなたが「プログラマー」ならば、この記事はまるで不要かもしれません。 ここで言うプログラマーとは、たとえば以下のような習慣を持っている人です。 ほとんど同じ処理をソースコード中に2回以上書いていたら違和感を感じる 出力結果が変わらなくても、実行速度や理解しやすさのためにソースコードを書き直すことがある Gitなどのバージョン管理システムを使うことができ、過去のソースコードを「日付の含まれたファイル名でバージョンごとに別ファイルとして保存しておけばよい」とは考えない 動作テストを自動化し、ソースコードを書き換えてもそれぞれの関数の挙動が意図したものになっているかを確認できる この記事は、ひょんなことからRに出会い、コードをコピペで動かせるようになり、 「いつかコピペじゃないコードが書けるようになりたい」 「他のプログラミング言語もできるようになりたい」 とぼんや
gitとプルリクエストに関して思うことまとめ - Qiita
※この記事は元々「Gitのこれやめて！リスト」として2015年11月に投稿したものを改訂したものです。 この記事について 私が個人的にgitとプルリクエストについて、「こうして欲しい」とか「これはやらないで！！」とか思っていることをまとめたものです。 元々は2015年に私がコードレビューをしてる時に気になったことを、あまり推敲もせず思うがままに書いた記事でした。今改めて読み返すと稚拙な文章なのと、他に思うところとがあったりしたので、改めて書き直しました。いいね貰ってるのに書き直すのに若干後ろめたさがあるのですが、よりいい内容にできればと思います。 コミットログがきれいだとレビューしやすい 一人で開発するときはgit使っててもブランチ切らないし、プルリクもださないしで、コミットログも"First Commit"の次が"Second Commit"とかでも支障はないです。しかし、チームで開発す
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
http://post.simplie.jp/posts/34