技術面接で出された問題 - ESM アジャイル事業部 開発者ブログ
9月に中途で入社した@wat-aroです． 前職はプログミングと全く関係のない仕事でしたが，プログラムを書く仕事がしたくて退職しました． 退職してからはまず基礎を身につけようとSICPを読み，ほとんどの問題を解き終わったのでFjrodのリモートインターンに参加して勉強していました． 今日は永和システムマネジメントの技術面接で出されたアルゴリズムの問題を紹介しようと思います． 出された問題はアナグラムの判定です． アナグラムとは文字列の順番を入れかえて，別の文字列になっているものです． eros と rose は文字の順番を入れ替えているだけなのでアナグラムです． eros と lose は文字を入れ替えただけでは一致しないのでアナグラムではありません． これを判定するコードを書きます． 面接ではRubyで書くのが難しければ疑似コードでもいいし，口頭でアルゴリズムを説明するだけでもいいと言わ
Python と Ruby と typing - methaneのブログ
うーん、structural subtypingとダックタイピングは同じものなんだろうか。— Yukihiro Matsumoto (@yukihiro_matz) 2016年9月8日 https://t.co/5Rv86piThC wikipediaによると似て非なる物のようですね。 https://t.co/VwIg39h5M0— INADA Naoki (@methane) 2016年9月8日 この話題について補足しておきます。なお、僕はTAPL脱落組なのであまり正確性は期待しないでください。 背景 Ruby Kaigi で Matz が Ruby3 に向けて考え中の静的型について話されたようです。 少し前から、 Python でも Guido が Dropbox での大量のコードベースを改善していくために type hinting がほしいということで PEP 484 を始めました
例外、エラー、異常、そして - Qiita
「例外」「エラー」「異常」あたりの言葉が、言語仕様や設計の中で人によって微妙にずれた使い方されてるから、 「Expected だが Accept されないケース」を表す別の言葉が欲しい。 — Jxck (@Jxck_) 2016年8月31日 @Jxck_ 本来こう分類されて、 1. Expected/Accepted 2. Expected/UnAccepted 3. UnExpected 2, 3 をどう呼ぶかあたりで、例外, エラー, 異常などの言葉が入り乱れてて、それが広義の例外処理が誤解される原因だと思ってる — Jxck (@Jxck_) 2016年8月31日 Expected and Accepted Expected but Unaccepted Unexpected
チームでコードを書き始めた後、「どうやらレビューってやつをした方が良いらしい」くらいの若手に向けた資料です。
code_review_basics.md コードレビューの基本 一番大事な事 ソースコードはプロジェクトの共同所有物である 誰かだけが触れるコードを無くす 自分だけが持っているコードを無くす 自分だけが触っている時間を短くする コードレビューで大事な事 コードレビューは... 相互学習型のプロセスである メンバが成長することが大事 相互学習とは レビュアーとレビュイーが、お互い学び合うこと 考え方を共有すること 質問することで学ぼう 一番できる誰かだけが教えるのではない 知識や経験の少ない人が何に躓いているのか学ぼう メンバの成長 同じミスをチーム内で繰り返さないことが成長 ミスを繰り返さないために 本人の問題にしない 明日はわが身 仕事の正しい手順を覚えよう 道具の正しい使い方を覚えよう コードレビューの心構え 伝えることが大事 改善するまでがレビュー レビューにコストをかけ過ぎない
チーム開発で暗黙的に行なわれている批評というプロセス - snoozer05's blog
Pull Request を通して行うコミュニケーションに「レビュー」という言葉がつくことに違和感を感じるときがあります。 Wikipediaでコードレビューを引くと、「見過ごされた誤りを検出・修正することを目的として体系的な検査（査読）を行う作業 」とあります。もちろん、これを目的として行うやり取りもあるのですが、その手前の「コードや設計について議論し、もっと良い判断を探る」ために行うコミュニケーションもあると思います。むしろ、そちらのコミュニケーションをやりやすいことが、Pull Request というプラットフォームが提供する価値なのではと感じることが多いのが、違和感の元かもしれません。 2015年6月に O'Reilly から出版された「Discussing Design: Improving Communication and Collaboration through Crit
オーディオアプリ開発でありがちな4つの間違い | POSTD
ここで論じているのは、オーディオアプリの開発者が陥りがちな 4つの間違い 、 より良く開発する方法 、 問題個所の発見方法 です。主に開発者向けの内容ですが、開発者以外の方にも知っておいてもらいたいと思います。ここでは、開発者向けの診断ツールである Realtime Watchdog を紹介し、 人気のあるオーディオライブラリの調査結果 を提示します。 オーディオアプリの開発はとてつもなく楽しいです。やりがいを感じるし、創造力を発揮できる範囲が大きく広がり、ひとたび開発が終われば、 誰かがクリエイティブなツールとして使ってくれるのです！ こんな分野は多くないし、この領域で働けるなんて非常に幸運だと自分でも思っています。 しかし、仕事でオーディオアプリを扱う時には深く考えなければならない部分もあります。オーディオアプリの開発者としてユーザに対する責任があるのです。大前提として、ユーザを公共の
システムプログラミング会 (2016/07/02 14:00〜)
会場説明: https://docs.google.com/document/d/1NshK51pNwKysrKLaBPHfS9T-4gkuZw-4-iszgT3qcHs/edit ハッシュタグ: #spkai システムプログラミングぽい人を適当に集めて話をしようという会です。なるべくみんななんか喋る感じが良いと思われる。俺を入れろって人も適当に連絡ください。他薦も歓迎。 なおシステムプログラミングに詳しいことを前提に話をするので、以下の一つくらいは満たさないと楽しくないと思われます: 「Lisp以上に複雑な言語処理系を作ったことがある」「オブジェクトファイルを読むプログラムを書いたことがある」「select系のものを使ってネットワークサーバを書いたことがある」「SIMD命令を使った最適化をしたことがある」 システムプログラミングがガチなひとの参加優先でお願いします。 現在の発表者リスト
マイクロソフト、プログラミング環境の共通プロトコルをオープンソースで提供
Microsoftはサンフランシスコで開催中のカンファレンス「DevNation」で、プログラミング環境の相互運用性を向上させる共通プロトコルをオープンソースで公開すると発表した。興味深いのは、この取り組みがCodenvyおよびRed Hatとの共同で進められていることだ。 このプロトコル「Language Server Protocol」（LSP）は、プログラミング言語をさまざまなコードエディタや統合開発環境（IDE）に統合するための共通の手段を提供する。LSPはさまざまなツールで多様なプログラミング言語を編集できるようにするもので、開発者の柔軟性と生産性を拡大することを目指している。 Codenvyの最高経営責任者（CEO）兼「Eclpipse Che」のプロジェクト責任者であるTyler Jewell氏は、「これまで、ほとんどのプログラミング言語は、1つのツールだけで最適化されていた
PythonからRubyに移行した人間の印象 - Line 1: Error: Invalid Blog('by Esehara' )
今日の料理 安物のねぎとろは、納豆と良くあう。 前提 はじめてのにき(2016-06-16) より。 このエントリの立ち位置について 元々はPythonを勉強していたのだけれども、仕事の関係上、Rubyを主軸にすることにした人間のエントリです。ちなみに、PythonとRubyの立ち位置には詳しくなく、主観を元に構成されているので、客観的な部分に関しては弱いことをお断りしておく。また、現時点での知識が2.7になっているので、3.5では多少違う点があるかもしれない。 なぜならPythonのほうが「わかりやすかった」から まず最初に、Pythonのほうが機械科学系の人に支持されやすい傾向としてあるのは、Pythonのライブラリ、例えばNumpyであったり、Scipy、または各種機械学習系のライブラリなどの影響が大きいのは間違いない。最近の機械学習ブームのせいなのか、Pythonも「エモい人(エモ
論文紹介: The Evolution of C Programming Practices: A Study of the Unix Operating System 1973–2015 - みずぴー日記
ICSE 2016勉強会に参加するために論文リストを確認していたら、40年間のC言語のプラクティスの変遷を追った論文がおもしろかったので紹介する。 対象の論文 論文: The Evolution of C Programming Practices: A Study of the Unix Operating System 1973–2015 論文中で使われれたデータ: https://github.com/dspinellis/unix-history-repo 要約 過去40年間のUnixのソースコードを分析し、コーディングスタイルの変化を調査した。その結果、以下のことが分かった。 新しい言語機能は価値のあるものならば採用される レジスタ割り当てをコンパイラに任せるようになる スペースをどこにいれるかなどのコードの書き方が統一されていく 分析対象 1972年以降にリリースされた計66個
（個人的に）IDEじゃなくてVim、Emacsじゃなきゃダメな理由 - Qiita
まえがき みなさんのお使いのエディタは何でしょうか。 きっとそのエディタは、自身のこだわりが幾つかあってそのエディタを選択したのだと思います。 私の身の回りにも当然IDE派とEmacs,Vim派が居て、Vim派の私はよくIDE派に「IDEをなんで使わないの？こんなに便利なのに？」的な姿勢で言われることが多々あります。（仕事でPHP書くので特にPHPStorm派などに…） IDEにはエディタ単体の機能ではVimは負けるかもしれませんが、個人的にはPCにインストールする系のIDEに共通する好きではないところがいくつかあって、私はVimを選択しています。その理由を記事にしてみました。 追記:2016-10-26 この記事は個人的にあまり他の記事でも語られていないなと思った、サーバーサイドのエディタで開発することの良さを書き記したものです。Vim自体、Emacs自体の良さにつきましては他にも優秀な
「現在時刻」を外部入力とする設計と、その実装のこと - クックパッド開発者ブログ
こんにちは。技術部 開発基盤グループの諸橋です。 クックパッドでは昨今の多くのWeb企業と同じように、GitHub EnterpriseのPull Requestを使ったコードレビューを広範に実施しています。わたしたちのコードレビューでは、ソースコードの字面にとどまらず、サービスの機能として魅力的かどうかや、保守性を含めた設計が適切かといった議論に発展することも良くあります。 きょうはそんななかで話題に上がった「現在時刻」の扱いかたに関する設計の話を書きます。 背景 サービスを開発・運営している我々には、時間帯によって出し分けたり、特定の期間のみに表示したいコンテンツがたくさんあります。 そのたびにデプロイし直すというのはつらいので(特に24:00に出なくなるコンテンツなど)なんとかしたくなりますが、一方で時限式のコンテンツはその時になるまでちゃんと動いているか確証が取れないので怖いです。
デザインパターンをチームで学んで得たもの - CARTA TECH BLOG
おはようございます、こんにちは。Zucks Affiliate事業本部でエンジニアをやっている新卒二年目のだっちと申します。 この事業部には最近部署異動で配属され3ヶ月ほど経ちました。 さて、今回は@t_wadaさんと事業部内エンジニアで毎週行っているJava言語で学ぶデザインパターン入門の読書会で得た知識によって設計の語彙がチームに浸透してきて円滑にリファクタリングの方向性が進んだ話をしたいと思います。 簡単な事業部紹介 Zucks Affiliateは名前の通りアフィリエイトを扱っている事業部で、エンジニアや営業間のコミュニケーションも盛んで日々雑談から事業・技術的な相談まで気軽にしています。 エンジニア間では朝・夕会でお互いにやっていること・詰まっている部分を共有しているのに加えて、コードは全員でレビューし、具体的に何をしているかがしっかりと把握できている状態になっています。 総じて
プログラミング 世代問わず受講の動き広がる | NHKニュース
コンピューターを動かすために必要な技術、プログラミングの教育が重要性を増すなか、子どもだけでなく、社会人の間でも、プログラミングの教室を受講する動きが広がっています。 また、別の企業が提供しているプログラミング教室では社会人を中心に受講者が増えていて、オンラインの教室も合わせると去年より３倍以上に増加しています。出版社に勤める女性の受講者は「今後ウェブサービスを立ち上げるために必要なスキルを身につけたい」と話していました。この教室を運営する「コードキャンプ」の池田洋宣社長は「プログラミングができることが社会人にとっての付加価値になってきていて、受講者は年々増加している」と話していました。 プログラミング教育を巡っては、中学校ではすでに必修化されていますが、政府は２０２０年度から小学校でも必修化を検討しています。 また、ＩＴ企業以外でもインターネット上のサービスが欠かせなくなっていることから
プログラムにコメント書かない文化もあるよって話｜NZ MoyaSystem
以下の記事を読んで。 530000micro.hatenablog.com 僕が勤めている会社では、原則、プログラムにコメントを書かないのがルールです。 人生で初めてプログラムに触れてからこのかた、プログラムには必ずコメントを書けと指導されて来ましたし、自分自身も、後輩たちにちゃんとコメント書けよと言い聞かせてきました。そんなわけで、最初に全然コメントのないソースコードの山を見たときは、正直「ゲッ、なんじゃこりゃ……」と面食らったのは確かです。 ところが、「なぜうちのプログラムにはコメントがないのか？」と同僚に尋ねてみると、実に納得の行く回答が返ってきたのでした。 なぜコメントが必要なプログラムを書くのか？ 同僚いわく、「コメントが無くても読めるようなプログラムを書け」という思想が根底にあるのだそう。 適切に関数や変数が命名され、スコープがきちんと管理され、ロジックの流れが整理されているコ
『10年のツケを支払ったフロント界隈におけるJavaScript開発環境（2016年4月現在）。 - 日々、とんは語る。』へのコメント
テクノロジー 10年のツケを支払ったフロント界隈におけるJavaScript開発環境（2016年4月現在）。 - 日々、とんは語る。
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GE: 今後採用する全社員に対してプログラミング能力を義務付け・採用職種に関わりなく - BusinessNewsline
プログラミングを楽しんで学べるSNSサイト「MOZER」
Apple、ゲーム感覚でSwiftアプリ開発を楽しく学べるiPadアプリを無償公開へ
【やじうまPC Watch】 生きた細胞の機能を改造するプログラミング言語をMITが開発
