一週間で身につくアルゴリズムとデータ構造|トップページ～プログラマーなら身につけておきたい、アルゴリズムの基本。入門編 このサイトは、すでにプログラミングの基本を身に付けたプログラマーが、アルゴリズムとデータ構造の学習サイトです。入門編では、最も基本的なアルゴリズムとデータ構造について説明します。プログラミングを始めたばかりか、これから学習する人は、こちらからスタートしてください。
他人のコミットをgit merge --squashするべきでないのではという話 - Qiita
最近某OSSに出されたPRが、git merge --squash <branch> でマージされたことにより、コミットのAuthorが書き換えられてしまったことが一部界隈で話題になっていました。この件にはマージを行った人に悪意はなかったようなのですが、gitの理解不足により生じてしまった案件だとすると悲しい話なので一応メモ 何が起きたか コミッターが複数の内容が含まれたPRを送った 管理者はその中の一部の内容だけをマージするために、管理者はgit merge --squashを実施し、コミットを改変した上でmergeを実施した ←これが問題 コードの内容はコミッターのものなのに、Authorだけ管理者にすげ変わってしまいコミッターのモチベを損ねた そもそもsquashするとどうなるの ここに分かりやすくまとまっています。 アジャイルSEを目指すブログ 図で分かるgit-mergeの--f
プログラミングにおける不安と学びのプロセス - 人間とウェブの未来
僕の場合、実現したいことをコードで書けない時には、ひたすら似たコードを読んで理解して写して…を繰り返す。そのうちに手元に大量の自分のサンプルが溜まっていく。その繰り返しがパターンの細分化を促し、書けるコードの幅を広げていく。書けるコードを気持ちよく書き続けてるだけでは新しいコードは書けないからだ....と、向き合えるようになるには時間がかかった。 書き慣れたコードの延長で書いていると、自分でコードを書けている実感があって、リファレンスなど何も見ずに自分の力でプログラミングできている感があるのだが、ある時これはただ「慣れ」の感覚を高めているように思えた。素早く書けること自体は、それはそれで一種のスキルで素晴らしいのだけど、実現したいことをコードで書けるようになる、という観点で振り返ったときに、どうしても成長を感じなかったのだ。それ以来、まずいと思い、実現したいことを思い描き、それを実現するた
「悪い方が良い」原則と僕の体験談｜Rui Ueyama
ソフトウェアの世界には「悪い方が良い」原則という有名なエッセイがある。キレイにレイヤ分けされた一貫性のある良いデザインよりも、一見手抜きっぽい悪いデザインのほうが実は良いときもあるという話だ。この逆説的なデザイン原則を僕は身をもって体験したことがある。それについてちょっと書いてみようと思う。 僕はlldというリンカの現行バージョンのオリジナル作者だ。リンカというのはコンパイラと組み合わせて使うもので、実行ファイルやDLLを作るのに使用される。lldはプロダクトとしてはかなり成功していて、標準のシステムリンカとして採用しているOSがいくつかあったり、GoogleやFacebookなど皆が知っているような大規模サイトの中で広く使われていたりする。 現在のlldは2世代目で、第1世代のlldは僕がプロジェクトに参加する前から存在していたのだけど、数年前にそれを捨てて一から書き直すということになっ
初級者から中級者にレベルアップするためのXcodeデバッグ術 - Think Big Act Local
効率よくiOSアプリ開発を行うために、効率よくデバッグを行いたいですよね。 このエントリでは「print文を書く以外デバッグの方法を知らなかったあの頃の自分」を初級者と定義して、自分がやってるデバッグ方法について書いてみます。 Xcodeデバッグ術 1. printを使わずに変数の中身を確認する age, name, coverImage という以下の3つの変数が宣言されています。 let age = 27 let name = "Ryosuke Hiramatsu" let coverImage = UIImage(named: "sample.jpg") これらの変数の中身をチェックしたい時、printで出力するのでも良いですが、それでは出力する値を変えたくなった時（print(age)をprint(age*2+1)に変更とか）に再度ビルドが必要になって時間がかかります。 printで
そろそろコードレビューそのものの必要性について考えるときがきているのかもしれない - タオルケット体操
技術ブログの方に書くか迷ったのですが、かなりポエムの類な文章になりそうなのでこちらに書きます。 ちょっと前にバズったこちらの記事 medium.com に触発されました。 ちなみにコードレビューに関する話としてはまだ僕が色々と手探りだった3年前にもこんなことを書いていたようです。3年前の自分の考えに触れられるブログって面白いなという気持ちとこいつどんだけ軽率な文章書いてんだよという気持ちが合わさり甘酸っぱい気持ちが生み出されました。 hachibeechan.hateblo.jp 当時と今では日本全体の技術的トレンドも変わっていますし、そもそも僕の所属している会社も違います。今の会社ではGitHubを使っており、コードレビューが当然のフローとして組み込まれています。 そしていま改めて当時のブログを読み返したのですが、びっくりするほどコードレビューに対する僕の考えが変わっていないので、改めて
JavaScriptで「(a ==1 && a== 2 && a==3)」の結果を真にする手法が議論される | スラド デベロッパー
JavaScriptで「(a ==1 && a== 2 && a==3)」という式の結果を真にするにはどうすればいいのか、StackOverflowで議論されている。 「aは1でもあり2でもあり3でもある」という状況は一見矛盾しているが、たとえばaをオブジェクトとし、文字列として評価されるごとに異なる結果を返すようにすれば簡単に実現できる。また、ホワイトスペースではなく文字として認識されるハングルの半角スペースを使って同じように見えるが実際は異なる3つの変数を定義するもの、getterを利用するものなど、さまざまな方法が提案されている。
Rubyのシンボルをなくせるか考えてみた（翻訳）｜TechRacho by BPS株式会社
概要 原著者の許諾を得て翻訳・公開いたします。 英語記事: Could we drop Symbols from Ruby? 原文公開日: 2017/10/02 著者: Robert Pankowecki サイト: Arkency この記事を読んでいる皆さまの場合はわかりませんが、私は個人的に文字列とシンボルの区別に由来するバグを余裕で10回以上は踏んでいます。このバグは私の書いたコードでも、他のライブラリを使うときにも起きました。私はコードに表示されるシンボルの外観は好きなのですが、シンボルと文字列の特定の区別のされ方が好きではありません。（こういうことを書くと炎上しそうですが）この区別は問題を解決するよりも作り出す方が多いと思います。 そこで私も考えてみました。いっそシンボルをなくしてしまえばどうだろう。過激な主張でしょうか？かといって、何千というRubyライブラリを書き直して、そこに
言語処理100本ノック2015 をRubyでやる【第1章】 - ようじょのおえかきちょう
自然言語処理を扱う研究室に配属になったので、この秋から課題として「言語処理100本ノック 2015」をやっています。先輩も同期も Python で書いているのですが、みんな一緒はつまんないので Ruby で書いてみることにしました。コードは GitHub に随時上げていきます。 github.com 最初の方こそググれば「Rubyでやってみた」記事が引っかかるのですが、途中から全くヒットしなくなるので悲しいです。これも続くかわかりませんが可能な限りやっていきます。 今回は第 1 章「準備運動」です。 00. 文字列の逆順 文字列"stressed"の文字を逆に（末尾から先頭に向かって）並べた文字列を得よ． 解答 puts "stressed".reverse Ruby では、引数のための小括弧は省略可能です。 puts("stressed".reverse) でもいいけど、書かなくてもわか
Nが現れる素数(N=1,2,3,4) - 技術メモ
2が現れる素数という面白い素数が紹介されていた。 2が現れる素数 - INTEGERS 昔せっかく高速素数判定器を作ったので、どうせならNが現れる素数を見つけてやろう！と思い立った。 プログラム （※プログラムはpython(2.7.12)で動作します） ルールとしては ①四隅のみの数字を変える（もちろん先頭は1以上の数字） ②四隅の数字はN以外の数字にする としています。 なので、それぞれ5832(8*9*9*9)個の数字の中から素数を探すことになります。 高速素数判定のプログラム（再掲） primechecker.pyという名前で保存 import random import numpy as np class PrimeChecker: def __init__(self, list_limit = pow(10,3)): if list_limit < 5: list_limit
オーバーフローが引き起こした面白いバグの話｜Rui Ueyama
一度聞いたら忘れられないような印象深いバグというものがある。僕は数値のオーバーフローと聞くと必ずこの2つのバグを思い出してしまう。どちらも面白いエピソードなのでちょっと紹介してみよう。 一つ目は、初代Civilizationにあったバグである。Civilizationは文明間で戦う戦略シミュレーションゲームで、チンギスハンとかエリザベス女王みたいなプレイヤーを選んで、世界制覇か宇宙開発競争での勝利を目指すというゲームだ。 初代Civilizationにあったバグは、非暴力主義のガンジーが突然核攻撃してくるというものだった。原因は文明が民主主義を採用すると攻撃性が2下がるというロジックだった。初代Civではガンジーの攻撃性は全プレイヤー中で最小の1なのだが、ゲームが進んでインド文明が民主主義を採用すると、攻撃性がマイナス2されてオーバーフローで255になり、ガンジーがゲーム中で突如、極度に攻
「ふつうのLinuxプログラミング」でLinuxの基本概念やシェルの仕組みについて学んだ - $shibayu36->blog;
最近golangでCLIツールを作っていたのだけど、Linuxのお作法とかいまいち分かっていなかった。そこでそのあたりのことが学べそうな「ふつうのLinuxプログラミング」を読んだ。 ふつうのLinuxプログラミング 第2版 Linuxの仕組みから学べるgccプログラミングの王道 作者:青木 峰郎SBクリエイティブAmazon この本はLinuxにおいてC言語でプログラミングする方法を、Linuxでの重要な概念も含めて教えてくれる本。この本を読めばとりあえずC言語を使ってLinux用のプログラムを書き始めることが出来るようになりそうだった。 それでC言語を使わない場合でも役に立つの？ということだけど、非常に役立ちそうで面白かった。なぜなら、単なるプログラミングの方法を教えてくれるだけではなくて、 Linuxの重要な考え方をファイルシステム・プロセス・ストリームという概念にまとめて教えてくれ
人間らしくコードレビューするには(パート1) | Yakst
自動化することによりあなたはレビュアーとしてより価値のある貢献ができるようになります。importsの順序やソースコードのファイル名の命名規約などの問題を無視できるならば、機能上の誤りや可読性の問題といった、より関心のある問題にフォーカスすることができます。 オーサーもまた自動化の恩恵を受けます。ケアレスミスを見つけるのに1時間浪費することなく、即座に見つけられます。即座にフィードバックを受けられることで、関係のあることがオーサーの頭に残り、これにより学習が容易となり、修正コストが低くなります。それに加え、彼らが初歩的な誤りについて指摘を受ける必要がある場合、あなたから指摘を受けるよりコンピューターから指摘を受けたほうが彼らの自尊心の観点からはるかに気分がよいわけです。 これらの自動チェックはコードレビューのワークフローの中に入れましょう(例えば、Gitのコミット前のフックやGithubの
pythonで小さなツールを作る時のtips - Qiita
自分で小さいツールを作る時に心に留めているtipsです． 書き始めたときは「どうせ書捨てだし」と思って書き始めると意外と長い間，もしくはいろんなところで使うことになったりするので，気をつけておくと後から楽になるというような小技です．大規模なソフトウェアの開発ではまた違った流儀があると思います． メインルーチンを関数にする 関数名はなんでもいいのですが，自分は趣味で main() という名前の関数を用意し，メインルーチンは全てそこに書くようにしています． pythonの小さなサンプルコードを見たりすると関数外の部分にベタで実行コードが書かれていたりします．もちろんそれでも動くのですが，以下の2点で後々面倒になることがあります． グローバル変数だらけになり管理が追いつかなくなる：「どうせ小さなスクリプトだし」ではじめると最初は見通しが良くてもだんだんどこでどの変数名を使っているか分からなくなっ
Go言語って何ででこんなに偏屈なんだろう | 非IT企業に勤める中年サラリーマンのIT日記
ざっくりGo言語を触ってきました。 今までJavaとかC#をメインに使ってきた僕としては、一見先祖返りしたような仕様にちょっと戸惑いました。 「コンパイル速度を上げる」目的で作った言語とのことで、その目的のためにコーディングしやすさをある意味犠牲にした、といいう点は理解できます。 が、明らかにコンパイル速度（あるいは実行速度）とは関係ないところで使い勝手を「わざと」悪くしたとしか思えない仕様に、Googleエンジニアの偏屈さを感じずにはいられません。 僕の単なる認識不足だけかもしれませんが、僕自身が感じた”偏屈”と思ったところを書いておきます。 ※アイキャッチ画像に自作Gopher君を載せていますが、Gopherの原著作者はRenée French氏です。 [ad#top-1] nullじゃなくてnil 「何もない」を表すnilですが、どちらかというとnullと表現する言語の方が多いです。
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
styleguide/ruby.ja.md at master · cookpad/styleguide
ksnctf
Elixir から Elm の流れで、いよいよオブジェクト指向に対する懐疑心が無視できないレベルに達した2017年冬。 – ゆびてく
優秀なプログラマーになるためのコツ
「グル」や「ウィザード」と呼ばれるレベルのハッカーになりたいです
