iOS Test Night #4 - connpass https://testnight.connpass.com/event/54316/ での発表資料です。 発表中で紹介した、Xcodeで実装⇄テストファイルにジャンプするスクリプトはこちら。 https://github.com/t…
新しい技術を学びはじめるとHello Worldのその先で何を作るか詰まってしまうことがよくある。 最初から作りたいものがある人はそれ作ったほうがいいし、実務で導入できたりするなら一番手軽で学びが多いのだが中々そうもいかないのが人生というもの。 そういう人にとってはHello Worldからある程度使えるもしくは本番投入時に選択肢にできるレベルになるための道筋があると便利だなーと思う。 自分はWeb系の人間なのでフロントエンド/サーバーサイド/モバイルアプリという感じでまとめてるが、インフラ屋やハード他デザイン系の技術はまた違うと思われるのでこれはあくまでも自分の場合はということで。 共通 言語機能を一通り試す(A Tour of Goみたいな感じで) 基本的な型/制御構造/IO周り/クラス/文字列操作/正規表現/よく使いそうな標準ライブラリ その言語固有の機能は重点的に(goだったらgo
こんにちは。 pixivの投稿ユーザ向けグロースを担当しているエンジニアのsestaです。 4月28日、ISUCON6本戦の問題を作ったedvakf、catatsuyと一緒に第2回社内ISUCONを開催しました! ISUCONとは3人までのチームで参加し、与えられたウェブアプリケーションのチューニングを制限時間いっぱい行い、パフォーマンスに基づいたスコアで競いあうコンテストです。 去年の社内ISUCON開催記事に引き続き、 今年は当日の様子のレポートとベンチマークなどの全体構成について紹介します。 当日の様子 今年は38人もの社員が参加し、その中にはなんと、ビジネス職の新卒や人事(!?)も参加していました。 競技時間は10:30から18:00までと本番のISUCONと同様にしました。 10:30によーいどんで始めた社内ISUCONですが、前半はなかなかスコアを伸ばすチームが現れませんでした
場違いすぎて自分がエイリアンに思えてくるような若い女性と子供のペアばかりの平日昼間のスーパーマーケットで懐かしい顔を見かけた。20年間実家に引きこもり続けているF。Fは僕と同じ歳なので現在43~4才。僕とFは小中高と同じ学校に通っていたけれど、同じ部活に所属したことはなく、数回にわたるロシアンルーレットじみたクラス替えを経ても《奇跡的に》一度も同じクラスになったことがない。誰にでもあると思うけれども、親友とは少し違う、一定の距離を置いて付き合っているような、ある種の緊張感漂う友人関係だった。唯一の共通項は子供の頃からピアノを弾いていたこと。一度だけ、どういう経緯でそんなことになったのか覚えていないのだが、高三の秋の放課後に音楽室に置いてあった埃の被ったピアノで、たまたま楽譜のあった「くるみ割り人形」を連弾したのは覚えていて、それはメタリカやガンズ&ローゼスで灰色に彩られた僕の高校生活のなか
SREの@deeeet です。 MercariではSlack Botを使い様々な業務の自動化を行っています。例えばメインのAPIのReleaseはBotによる自動化がされており、JPとUSとUKの3拠点で1日に10回以上のReleaseをSlack上で実現しています(これ以外にも多くの事例があります)。 これまでのSlack Botは基本的には文字ベースでのやり取りが普通でした(グラフなどの画像を返答として利用することはあります)が、SlackはよりInteractiveなやりとりを実現できるInteractive Messageという仕組みも提供しています。これによりButtonによる決定やMenuによる選択といったアクションをユーザにとらせることができるようになります。 Buttonの仕組み自体は古くから提供されていましたが他のTeamへの配布が前提でありOAuthの仕組みを準備する必
こんにちは。メドピアにjoinして3ヶ月目の保立です。 毎週のように新しい開発が進むため、毎日楽しくソースコードを書かせてもらっています。 テストコードを制するものは、Railsを制す!!! ということで、今回はメドピアのRSpecについてです。 メドピアでは、RSpecを用いてテストコードを書いており、 - 1) models配下に記載するビジネスロジックに対するUnitTest - 2) 機能ごとのEndToEndTest (E2E Test) の2種類のテストコードを書いています。 RSpecについて、書こうと思ったきっかけ RSpecは(というかRuby自体が)様々な書き方で動かすことができるため、統一したルールがないと、書いた人によってバラバラなテストコードになります。 私も初めてRSpecを書いた際に、参考書やソースコードによって書き方がバラバラで、どのRSpecを参考にすれば
開発部 R&D グループの村田 (mrkn) です。 2017年05月19日、Speee Lounge で DataScience.rb ワークショップ 〜ここまでできる Rubyでデータサイエンス〜 を開催しました。 このワークショップは当初、私が2016年10月から取り組んでいる PyCall の開発 *1 と、Ruby アソシエーション開発助成の支援の下で実施された西田さん、三軒家さん、芦田さんによるプロジェクトの成果報告のために企画されました。そんな中、クリアコードの須藤さんが2017年2月頃から Apache Arrow の Ruby バインディングを開発する Red Data Tools プロジェクトを開始されました。Apache Arrow は2016年頃から開始されたプロジェクトで、私は当初から Ruby の将来にとって重要な基盤になるはずだと思い注目していたこともあり *
様々な事情があってしばらく自宅警備員をしながら転職活動をしていたのですが、ようやく落ち着いたので書いています。 タイトルちょっと煽り気味ですが、今回の転職活動では20社くらいの話を聞いたりしていました。 そこで「なるほどなぁ」って思うこともあったのでちょっとまとめてみようかなと思った次第です。 記事をを書くにあたっての前提として、自分のステータスですが 後期アラサーなので社会人経験も人生経験がそれなりにあり、第二新卒ではもうないし、「若手」とも言えずベテランに片足突っ込んでる感じ 人材紹介会社にいたりコミュニティにいたり採用人事やってたりなどしているので、IT業界の他社のことはなんとなく情報が自動的に入ってくる (転職活動の中で気づいたことだが)経験年数の割にどうやら仕事上の修羅場経験はそこそこある 今回は人事とかバックオフィスとかのいわゆる「ビジネス系職種(エンジニアではない)」で転職活
この世には、ダウンすることが許されないシステムが存在する。金融機関の基幹系、原子力発電所や鉄道の制御システム、流通業の物流管理システムなどはもちろんであるが、最近ではtoCのサービスでもダウンタイムが長くなると大事件として騒がれ、ヤフトピに載ってしまったりする。 ではダウンへの対策はどうするかというと、いくつか手法はあるのだけど代表的なのは「冗長化」である。簡単に言うと、全く同じシステムを裏側に待機系として用意して、有事の際は自動的に切り替わるようにしておくのである。素朴だが、殆どのシステムではこの種の仕組みを用意している。 それでうまくいけばいいのだけどじつは、この待機系への切り替えというのは鬼門であり、高確率で失敗する事になる。 [続報]東証のシステム障害、原因はハードウエア故障後の切り替えミス http://itpro.nikkeibp.co.jp/article/NEWS/2012
待望されたYarnサポートの入ったRails5.1が2017年4月にリリースされました。 Ruby on Rails 5.1 Release Notes — Ruby on Rails Guides 他にもjQueryがデフォルトdependencyから外されたり、Optionalでwebpackサポートが入ったりしており、Railsのフロントエンドは大きな転換点を迎えたと言ってよいでしょう。本エントリではRailsのフロントエンド技術の今を振り返り、今後どうなっていくかをまとめてみたいと思います。 DisられてきたRailsフロントエンド Railsのフロントエンド技術スタックは、フロントエンドを専業とするエンジニアにDisられるものでした。具体的には下記の技術要素です。 jQueryCoffeeScriptAssets Pipeline (sprockets)gemのエコシステムに乗っ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く