タグ

ブックマーク / bugrammer.hateblo.jp (13)

  • 他人の技術に興味や関心を持つということ - Line 1: Error: Invalid Blog('by Esehara' )

    暫くスタートアップのお手伝いをしている。最近やったのだと、下のような感じ。 jeffh/sniffer · GitHubを使ってSphinxでDocstringをぶん投げる DjangoとJenkinsを連帯させ、ローカルでテストを廻す blockdiagを使ったモデル関係の整理 Muninを導入して、落ちる原因になってるサーバーリソースの監視 Hipchatを使っているので、GitHubやPivotal Trackerを連携させる Hipchatの遊び心としてHubotの導入 django開発の基礎としてBeProud社の『Pythonプロフェッショナルプログラミング』を薦める そんな感じ。上のことがどれだけ効いているかはわからないけれど、自分が楽しんでやれる環境に整備し、あとは他の人にも「だいぶ楽になったなー」という気持ちになれれば、こっちとしては万々歳。もしかしたら半分くらいは自己満

    他人の技術に興味や関心を持つということ - Line 1: Error: Invalid Blog('by Esehara' )
    sh19910711
    sh19910711 2021/07/18
    "一人が技術について面白がったり、出来るだけ色々な話題を共有できる土壌があり、トップもそれに好感があると、良い雰囲気になるのかなという気がしている"
  • 『オープン・デザイン』は、むしろプログラマが読むべき本だった - Line 1: Error: Invalid Blog('by Esehara' )

    今日の十六茶 試してガッテン方式で入れている。 はじめに オライリー社から2013年に発売された『オープン・デザイン』というは、率直に言ってしまえば、如何にもデザイナー向けの思弁的な議論のアンソロジーとなっている。それらは、直接的には技術的な洞察を与えるものではないだろうし、また同様に、それが直接的に業務に使えるものかといったらそうでもない。 そうではないのにも関わらず、このは、プログラマにとって重要なであることは間違いないと、僕は確信している。逆説的なことではあるが、この技術書でないからこそ、あまりにも無視され続けたであると思うのだが、だからこそ、今読むべきであると思う。 プログラマはデザインが下手であるという現実を直視する もちろん、デザインという言葉は多義的な言葉であることは間違いない。まず指摘できることは、日語の場合、デザインという言葉は「設計」という言葉ではなく、

    『オープン・デザイン』は、むしろプログラマが読むべき本だった - Line 1: Error: Invalid Blog('by Esehara' )
    sh19910711
    sh19910711 2020/08/10
    "特定なデザインの妥当性はクリエイターによってではなくユーザーによって決定 / デザインの中に「ユーザー」という登場人物が出てきたことは考慮すべき問題 / そのユーザーの中にわれわれがいる"
  • Pythonを退職します - Line 1: Error: Invalid Blog('by Esehara' )

    Pythonが嫌いになったの? Pythonについて嫌気が差したとか、Pythonが嫌いになったわけではありません。これからも一番好きな言語は恐らくPythonですし、実際のところ、機会があればPythonは書こうと思います。ですので、決して言語としてPythonが嫌いになったわけではありません。 そもそも、職業プログラマとして、ちゃんとしたオブジェクト志向を教えてくれたのはPythonでした。Pythonは、その言語仕様からして、出来るだけ簡潔かつ、綺麗に書けるし、Pythonについて深く知れば、プログラミングとはどういうことなのかについて、詳しく知れるほどの、わかりやすい言語であることは事実ですし、初心者向け言語として、Pythonは強く押したいという気持ちは今も変わりませんし、ずっとPythonならびにそのコミュニティに関して感謝の気持ちはずっと忘れないでしょう。 また、近年ではPy

    Pythonを退職します - Line 1: Error: Invalid Blog('by Esehara' )
  • Word2Vec + MeCabで「ボケる」ための単語候補をピックアップするやつをやってみる - Line 1: Error: Invalid Blog('by Esehara' )

    近況 はじめに 最近、ちょっと大喜利を始めていて、如何に面白いことを言えるのか、ということを考えたりしているんだけど、考えてみれば、自分は少しプログラミングができるし、むしろ形態素解析や自然言語処理という観点から「質問」と「ボケ」を考えてみると面白いかもしれない、と思って、力技でそういうことをやってみた次第。 今回の方針 とはいえ、何となく「質問に対して上手いボケを返してほしいな」ということであるならば、それこそ単語のランダム検出でもいいという話になってしまうので、ある程度仮説を立てて実装する。今回の仮説としては、「ある文が連想する知識の、派生する知識がその文と結びつけられた場合、人は上手いと思うのではないか」ということだ。 どういうことか。 例えば、謎かけの場合、「Aとときまして、Bととく。その心はCです」と言った際に、一見無関係の文(あるいは単語)が、Cという意味づけによって接続するこ

    Word2Vec + MeCabで「ボケる」ための単語候補をピックアップするやつをやってみる - Line 1: Error: Invalid Blog('by Esehara' )
  • ポモドーロ・テクニックを二ヶ月やってみた感想 - Line 1: Error: Invalid Blog('by Esehara' )

    二ヶ月間ポモドーロテクニックをやってみての雑感 だいぶ知見が溜まってきたので、セーブがてら記事にしておく。 方法 要するに 25分、集中してそのタスクをやったら5分休む = 1Pomodoro 4Pomodoroやったら15分休む というのを繰り返すというだけだ。 実際の運用 確かにもう少し厳密なフローとしては、例えばTodoリストを作成したり、それに対しての見積もりをする、という方法もあるのだけど、自分はそういう網羅的なToDoを作成するのが苦手だったりする(むしろ作業中にどんどんToDoを積み上げていくという方法)のほうが好きだったりするので、そういう風にしている(最初から完璧にやろうとすると絶対無理なので)。 意外とやってみてよかったというのは、集中できたときのアクティビティを記録しておくという方法だ。要するに何時にポモドーロテクニックを集中できてやれたのか、というのを一つずつ記録し

    ポモドーロ・テクニックを二ヶ月やってみた感想 - Line 1: Error: Invalid Blog('by Esehara' )
  • PythonからRubyに移行した人間の印象 - Line 1: Error: Invalid Blog('by Esehara' )

    今日の料理 安物のねぎとろは、納豆と良くあう。 前提 はじめてのにき(2016-06-16) より。 このエントリの立ち位置について 元々はPythonを勉強していたのだけれども、仕事の関係上、Rubyを主軸にすることにした人間のエントリです。ちなみに、PythonRubyの立ち位置には詳しくなく、主観を元に構成されているので、客観的な部分に関しては弱いことをお断りしておく。また、現時点での知識が2.7になっているので、3.5では多少違う点があるかもしれない。 なぜならPythonのほうが「わかりやすかった」から まず最初に、Pythonのほうが機械科学系の人に支持されやすい傾向としてあるのは、Pythonのライブラリ、例えばNumpyであったり、Scipy、または各種機械学習系のライブラリなどの影響が大きいのは間違いない。最近の機械学習ブームのせいなのか、Pythonも「エモい人(エモ

    PythonからRubyに移行した人間の印象 - Line 1: Error: Invalid Blog('by Esehara' )
  • 迫り来る「forおじさん」と呼ばれる時代 - Line 1: Error: Invalid Blog('by Esehara' )

    はじめに 今となっては、プログラマにとってなんとなく理解して利用できることが当たり前になりつつあるオブジェクト指向ですが、しかし、それこそ今から数年前には、この「オブジェクト指向」というのは、いわばおじさん達が変な方針を打ち出したりして「え、それ変な実装方針じゃねえの」というツッコミが入ったりしていました(ちなみにそのあたりの雰囲気については、この記事を読むと分かりやすいでしょう)。 もちろん、これはこれなりにメリットがあるのかもしれませんが、しかしそれはまた別のオブジェクト指向を利用したモデリングと比較してのことであって、「これだけでいい」と考える人はいないでしょう。 原則: だってそのほうが開発しやすいから まず最初に原則を考える必要があります。まずひとつに、必ずしもオブジェクト指向が正しいモデリングの方法ではないこと。少なくとも自分が思うに、オブジェクト指向を使うべき理由というのは、

    迫り来る「forおじさん」と呼ばれる時代 - Line 1: Error: Invalid Blog('by Esehara' )
  • 一人でコードを書きなさんな - Line 1: Error: Invalid Blog('by Esehara' )

    とりとめのない話をメモがてら。 最近、コードを読むことが多くあるのだけれども、「このコードは一人で書いているな」という感想を覚えることが多い。もちろん、基的にはコードというのは、物理的には一人で書くものであるのは間違いないのだが、たぶん、それとはまた別種のものだ。 僕がこの世界でメシをう数年前に、PHPユーザーは他の言語を知らないから、他の言語の良いプラクティスを知らないという批判が議論を呼んだことがあるようだ。このさいPHPはどうでもよく、問題は「他の言語の良いプラクティスを知らない」ということだ。プログラミング言語というのは、そのときに共存しているお互いのパラタイムと関係している。例えば、最近ならJava8がOption型を導入しようとしているのは、やはり「関数型言語」というのが成熟してきて、その方法論が有益なものとして受け止められるようになってきたからだ。C++もラムダを取り入れ

    一人でコードを書きなさんな - Line 1: Error: Invalid Blog('by Esehara' )
  • ユニットテストを書かないことについて - Line 1: Error: Invalid Blog('by Esehara' )

    はじめに 最近は、同じ職場で働いている人に対して、『テスト駆動開発入門』のを貸したり、自分自身でも全く更地のところにユニットテストを書くという作業をやったり、あるいは実装中にもユニットテストを書かないと、コードを書く手が少し滞ってしまうくらいには、テストに依存している自分がいる。 さて、ここ最近で一連のテストの話が各方面から出ていて、それらの議論について興味深く感じる一方で、たとえば自分はそうだけど、「執拗にテストを書いているけれども、これで前に進んでいるんだろうが」という罪悪感みたいなのを抱えている人というのは、それなりにいるんじゃないかと。特にユニットテストを腐らせて、テスト自体を負債にしてしまった人であるなら特に。 ここ最近の、アジャイル開発であったりとか、あるいはプログラマのためのみたいなのを開いたりすると、たいてい「他のことは良いからテスト書け」と載っている一方で、見回してみ

    ユニットテストを書かないことについて - Line 1: Error: Invalid Blog('by Esehara' )
  • Vim Conference 2013とオープンソースの精神 - Line 1: Error: Invalid Blog('by Esehara' )

    Vim Conference 2013にお邪魔。 基的に、自分は何か思いついたことがあるとすぐに「何か発表させてくださいよー」ということで、LT枠か、発表者枠でネタを提出するわけですが、今回も「じゃあEmacsのevil-modeの話をするわ」という変化球を投げたところ、あっさりキャッチされてしまったので、発表させていただきました。少々準備不足の点もあって、退屈であった点は幾つかあったと思います。というわけで、自分のスライドは下にあげて、今回は自分の話を飛ばして話させて頂ければと思います。 オープンソースの精神 自分が、そもそもエンジニアの世界に入ろうとしたきっかけというのが、オープンソースというありかたがとてもキラキラしていたから、というのは、実は一つあります。オープンソースというのは、基的には「自分が必要だから」「自分が楽しいから」書かれるものですが、どうせ自分で書いて、それが企業

    Vim Conference 2013とオープンソースの精神 - Line 1: Error: Invalid Blog('by Esehara' )
  • 重要なのはオブジェクト指向じゃないと思うんだよ - Line 1: Error: Invalid Blog('by Esehara' )

    最近になって、オブジェクト指向がよくわからないという御仁とご一緒することになった。別段、それ自体が悪いことではない。確かに、その人の書いた、以前のコードというのはめちゃくちゃであった。当然のことながらif文は何十にも繰り返されているし、その中でネストが3つにも4つにも増えていくという恐るべきコードだ。そして、どうやら僕の前に、教えてくれた人がいるらしく、その人に「オブジェクト指向というのを教えてもらったから、もう少し上手く書けるようにになっている筈だ」ということを言っていた。 僕はそのことに、特段ケチをつけたいとは思わない。誰だって無知から始まる。僕もオブジェクト指向にとんちんかんなことを言って恥をかくことがある(もしかしたらこれからもね!)。無知が恥なのではなく、学ばない姿勢が恥なわけだから、僕はそういうのはいいなあ、と素直に思える。しかし、どうも僕は引っ掛かっていることがある。それをメ

    重要なのはオブジェクト指向じゃないと思うんだよ - Line 1: Error: Invalid Blog('by Esehara' )
  • プログラムを書く順番とテスト駆動開発について - Line 1: Error: Invalid Blog('by Esehara' )

    下のを読んでいた。 プログラミングの基礎 (Computer Science Library) 作者: 浅井健一出版社/メーカー: サイエンス社発売日: 2007/03メディア: 単行購入: 17人 クリック: 409回この商品を含むブログ (105件) を見る このはどういうかといえば、OCamlという、関数型言語と呼ばれる中でも、あまり有名ではないほうの言語(というと失礼だけど)を使ってプログラミングの基礎を学ぶという。そういうと、OCaml好きな人には怒られるかもしれないけれども。 良いにしろ、悪いにしろ、関数型言語の特徴は、個々のパーツを作って云々という部分が非常にクリアーになっているところであるな、とは思う。というのも、下手に「代入」を使わないことによって、むしろデータ操作の流れがクリアになるし、余りに大きいパーツにしてしまうと、そもそもその流れ自体がよくわからなくなる

    プログラムを書く順番とテスト駆動開発について - Line 1: Error: Invalid Blog('by Esehara' )
  • 本を読むコツとしての「わからないところは飛ばす」 - Line 1: Error: Invalid Blog('by Esehara' )

    はじめに 一時期、自分は一週間に三冊のを消化することを目標にしていたことがあった。 もちろん、それでの内容を理解したとはとても言いがたいとは思うし、今はほぼやっていない。しかしそういう多読スタイルを続けていると、不思議なことに、おぼろげながらに「型」というものが出来てくる。どのようなアプローチでに取り組むべきなのか、ということがだいたいわかってくる気になる。 今回はその話をメモしておこうと思う。 追記 ちょっと誤解を生みやすいみたいなので、ここで補足します。 これから語られることは、どちらかというと「ちょっと難しいを少しずつ砕きながら読む」という形なので、例えば小説であったり、簡単なエッセイとか、そういうの読み方として期待するとちょっと違うという印象になるかもしれないです。 上のような記事を期待されたかたは、恐らくがっかりすると思うので、追記しました。 最初から全部理解してやろう

    本を読むコツとしての「わからないところは飛ばす」 - Line 1: Error: Invalid Blog('by Esehara' )
    sh19910711
    sh19910711 2013/07/15
    飛ばしたところに付箋貼る方法いいな
  • 1