［速報］「Kotlin」がAndroidの正式な開発言語に。開発元のJetBrainsとGoogleが「Kotlin財団」の設立も計画。Google I/O 2017 Googleが5月17日（日本時間5月18日未明）から開催中の年次イベント「Google I/O 2017」。初日の基調講演では、新サービス「Google Lens」の紹介や「Google Home」の日本発売、「Cloud TPU」や「TensorFlow Lite」の発表、新興国向けのエントリクラスとなる「Android Go」の発表などが相次いで行われました。 しかしその中でも会場からもっとも大きな歓声があがったであろうと思われるのが、プログラミング言語の「Kotlin」がAndroidの正式な開発言語になると発表されたときでした。 「Kotlinは完全にAndroidのランタイムと互換性があり、既存のコードとも相互運

ワケ一覧 序の口: フレームワークだけが負債だと思ってる 序二段: ビジネスサイドに理解してもらう努力がない 三段目: 技術で遊び過ぎてしまう 幕下: 太り過ぎアーキテクチャ 十両: 過去に目もくれず、現状だって見ない 前頭: 技術に詳しいだけでアーキテクト 小結: アーキテクトの知識と覚悟が足りない 関脇: スパンが長く、モチベーションが続かない かど番大関: スパンが長く、人の入れ替えでチグハグ 大関: アーキテクチャデザインはどこへ？ 横綱: 実は人間的負債だった 序の口: フレームワークだけが負債だと思ってる みんな、フレームワークが大好き。とはいえ、さすがにみんな、「フレームワークが古いことだけが負債」だなんて思ってないはずだが...なのに多くの人が、あたかもそのような振舞いと判断をしてしまう。潜在意識の Big Issue だから？ o 信用できないテストデータ も負債 o 現

私たちの救世主DHH™は最近の Full Stack Radioのインタビュー で、 Basecamp の最新版で彼がどのようにRailsのコントローラを書いたかを説明しています。下記は、彼のすばらしい話を書き取ったものです。 これまでに思うようになってきたのは、「RESTの原則に従うには、どのタイミングで新たなコントローラを作るべきかを一度決めたら、ほぼ異例なくその原則を遵守するべきだ」ということです。いつだってその方がうまくいくんです。自分の作ったコントローラの状態を悔やむのは決まって、作ったコントローラの数が少なすぎた時です。多くの処理を任せようとしすぎてしまうんです。 そこでBasecamp 3では、ある程度理にかなったサブリソースがあれば、毎回コントローラを分割していきます。フィルタなどの場合ですね。例えば画面があって、それがある状態になっているとします。もしこれにいくつかのフィ

初めに 新規プロジェクト／既存プロジェクトで、新しく使う ライブラリだったり、フレームワークだったり、ミドルウェアを選定してきた経験を通して、 採択する段階でこれはしておいた方がいいなという知見が溜まったので、 メモ書き程度に記述します。 前提として、技術採択についてある程度メンバーに裁量が任せられている風土があり、 かつミッションクリティカルでないシステムに導入する、また自社で事業を行っており、 顧客＝ユーザーであるというのがあります。 (この辺の前提条件が違う場合、採択に当たってまた別の観点が必要になってくると思います) システム要件を満たしているかどうか なんだかフワっとした言い方になりましたが、例えば Web システムに JavaScript のライブラリを 導入する場合に、Web システムが IE8 に対応するという要件ならば、 そのライブラリが、IE8 でも動くか調査するという

この記事は、はてなエンジニアアドベントカレンダー2016の12日目の記事です。 先日こういうツイートをしました。 Redisはキャッシュ用途のミドルウェアだと思わない方が良いと思う — songmu (@songmu) 2016年12月10日 言いたかったのは、Redisはキャッシュのためだけのミドルウェアだと誤解されがちなのですが実際はそうではないということです。実際、公式サイト を見に行くと以下の様なことが書かれています。 Redis is an open source (BSD licensed), in-memory data structure store, used as a database, cache and message broker. つまり、Redisは多彩なデータ構造を保持できるインメモリーのデータストアで、様々な活用法があり、キャッシュとして「も」使える、とい

ドラゴンボールに超とんでも外伝が登場！主人公はまさかの…アイツ!!最強を目指し、とてつもない修行にチャレンジする…!? 原作小説「カラダ探し」（スターツ出版）シリーズ累計１９万部突破！ 詳しくはコチラ

先週書いた10年のツケを支払ったフロント界隈におけるJavaScript開発環境（2016年4月現在）。という記事がまずまずの反響を得たのですが、僕の予想とは異なり、「こんなに多くのツールやフレームワークを必要とする現状はおかしい」といった、状況批判の意見が多く集まりました。 Mediumなど海外メディアでは、もはやこの種のツールを組み合わせたフロントエンド開発が当たり前として受け入れらており、この半年間ほどは「実際にどの組み合わせがベストか」という議論が行われていました。そして、そういった議論もようやく落ち着きを見せ、おおよそ僕が書いたような組み合わせに帰結しつつあります。 そのため、まさか「フロントは変化が激し過ぎる」とか「保守が大変そう」などといったような、1年くらい前に言われていた意見が、いまだに多くを占めるとは、まったく予想していなかったというのが正直な意見です。ひと昔まえであれ

Help us understand the problem. What is going on with this article? 3月24日に発表になったLINEのBOT API Trial Accountが、いよいよ4月7日から実際に試せるようになりました。既に多くのBOTが開発者の手によって作られ始めたようですね。QiitaにもいくつかBOTの作り方が投稿されていますので、"LINE BOT"というキーワードで探してみてください。 実際の作り方の基本は他の投稿に任せるとして、BOT API自体は非常にシンプルな作りなので、試すこと自体はすぐにできると思います。しかし、シンプルな反面、仮に近い将来「Trial」が取れて、友だち50人制限が撤廃された時、それでも正しく安定的に動作するBOTとするには、アーキテクチャ上の工夫が必要になります。個人的に、既にLINE BusinessCo

コードレビューで土日に安寧を ソーシャルゲームは、ユーザアクセス集中と、それに伴うユーザデータ増加によって劇的に負荷が上がり、（主に土日に）サービスに影響を与えがちです。 問題があるコードは、たとえ負荷テストを行っても、作成したシナリオによっては見つけられない可能性もあります。 そういった見えない不安を払拭するという意味でも、コードレビューは重要だと思っています。 【ステキポイント】 ・ ソースを見ることにより、時限爆弾が土日に爆発するのを解除 ・ スキル共有によってメンバーがレベルアップすることにより、土日に爆発する時限爆弾の設置確率低下 まぁまとめると これに尽きます（4歳の息子談） 今は、gitのプルリクエストという強力なレビューツールもあり、敷居がかなり低くなったのでオススメです！ チェックするポイントは5つ コードレビューを行うにあたり、「どんなところをチェックすればいいのか分か

別のことを先に書こうと思っていたが、時事ネタなのでササっと書いてしまう。 「はてな」トップの「エンターテイメント」に、大相撲春場所千秋楽の結びで白鵬が見せた変化に対する記事が2件並んでいた。 スポンサーリンク 痛いニュースと… blog.livedoor.jp 札幌訪問型鍼灸治療院つちだ さんのところの記事である。 www.cloudsalon.net 私の意見は後者のブコメに書いた通り、「変化がある」という可能性はないよりあったほうが面白いし、変化をルールで禁じるなんてとんでもない、というものだ。むろんそうでない意見も多い。異なる意見があることは当然だ。しかし私と異なる意見のブコメを読んでいて、何となくモヤモヤと感じた違和感を言語化できそうな気がしたので書いてみる。 それは、「明文化されたルールより不文律を尊重すべき」とでもいうような空気だ。 大相撲で変化をルールで一律に禁止することはで

月渡ねこ（おっさん） @tukiwatari 海外でデザイン関係のコーディネーターやってる友人が「日本のクリエイター（主におたく方面）はどんな好条件で誘ってもなかなかこっちで仕事しようとしてくれない。言語の壁は完璧にサポートする。待遇もいい。なによりすごくリスペクトされるのに。なぜだ。」って悩んでるんだけど（続く） 月渡ねこ（おっさん） @tukiwatari （承前）日本のオタク系クリエイターと呼ばれる方々は近所のファミマとか、通ってるラーメン屋とか、Skypeで通話しながら遊べる友人とか、声優イベントやってくれるグッズショップとか、フラゲで新刊漫画が買える本屋とか、ニチアサキッズタイムの実況とか、そういう環境に重心を置いて（続く） 月渡ねこ（おっさん） @tukiwatari （承前）そこからあれこれ創出してる気がするので、そういった事情を説明して「油田は動かせないんだ。つまりヨーロッ

概要 お願いした作業の進捗を聞くときには「進捗どうですか？」より「困ってますか？」と聞くほうが何倍も捗るよ、というお話。 タイトルの2015倍は冗談です。念のため。 「進捗どうですか？」はダメです あけましておめでとうございます。ところで皆さん進捗どうですか? ・・・いやー、流行りましたね。 この「進捗どうですか？」はtwitter上で使うと「最近どうよ、忙しいの？」程度の挨拶で面白みがあるのですが、実際に仕事で使うとなんのいいこともないと思うのです。 質問攻め いいことがないと思う理由は、「進捗どうですか？」は質問攻めになりやすいと思うからです。「進捗どうですか？」の先に待っているやりとりはだいたいこんな感じです。 「進捗どうですか？」 「進捗ダメです。」 「どこがダメなの？」 「単体テストが遅れています」 「どれくらい遅れてるの？」 「えーと・・・、0.5日分くらいです」 「項目数でい

マイクロソフトの DevOps テクニカルエバンジェリストになる前から、ずっと不思議だったことがあります。 それは、「アメリカのエンジニアの生産性の高さ」です。素晴らしいサービスは大抵彼らから生まれていますし、彼らを見ているとアウトカムも生産性も非常に高く感じます。 私は個人的にこの秘密を解く旅の途中にいます。私はインターナショナルチームに所属しているのですが、同僚と一緒に働いたり、ハッカソンをしたりして気づいた１つの仮説について共有したいと思います。 気軽に「聞けないこと」が生産性を阻害しているのでは？ 以前私は「米国のエンジニアはコンピュータサイエンスを専攻している人が多くすごく優秀で、さらに英語が出来るので、技術収集するのも楽だから相当アドバンテージがある」と思っていました。 英語に関してはそうだと思いますが、彼らの個々の人がそんなに優秀かというとそうでもないことに気づきました。それ

重要なのは、この「煩わしさ」は、「そのタスクを完了した際に、どれだけ体力と意欲を使い果たすか」 の指標であることです。 「技術的には難しくないから、経験の浅い人にまとめてやってもらおう」と、そうした「だるいタスク」を集中させてしまうと、あっという間に人員が疲弊して 最悪離職します 恥ずかしながらこういう経験があります。 「だるさ見積り」した => 予測工数の -5%〜+5% の前倒しor遅延 で済んだ 「だるさ見積り」しなかった => +20%〜40% も遅延した。 終わった後の生産性の低さも本当にもう酷かった。 ごめんなさい。。。。 やろう！『だるさ』見積り！本当に大事だよ！ [見積もり編] 3. OKR を意識したバックログ 具体的には Github の issue サマリを記載していく事柄で実践します Objectives : この PullRequest で何ができてほしいのか サ

開発部の@horimislimeです。普段は@y_koh さんとiPadアプリ開発をさせてもらっています。 先日トレタはメジャーアップデートとなるver5.0.0で、飲食店従業員の方が店内のテーブル配置を作成し、空間的にテーブルを見ながら予約を取れる「テーブルレイアウト」機能をリリースしました。 この機能の詳細や、開発にあたっての想いは弊社ブログのエントリも御覧ください。 トレタ新バージョン「5.0.0」とモノ作りの話 : TORETA（トレタ） ブログ トレタとして大規模なアップデートとなるver5.0.0でしたが、その裏ではiOS開発チームとして新しいチャレンジもありました。それが以下の二点です。 Swiftと新しいパラダイムの導入 これまでのトレタには無かったUIの実現 まずiOS開発チーム内でこの新機能からSwiftを導入し、合わせてMVVM風な設計を取り入れつつ実装を進める方針を

The most amazing feature of Parse Server is that it’s accessible for developers of all skill levels. Personally, I started playing around with Objective-C in 2012. Parse was a way for me to build a complete online app, without having the in-depth knowledge of how to build networking, storage, user systems, etc. The more I built with Parse, the more I learnt JavaScript, which has fortunately allowe

記事のタイトル通り、競馬で回収率100%を超える方法を見つけたので、その報告をする。 ちなみに、この記事では核心部分はぼかして書いてあるため、読み進めたとしても「競馬で回収率100%を超える方法」が具体的に何なのかを知ることはできない。（私は本当に有効な手法を何もメリットが無いのに公開するほどお人好しではないので） 本当に有効な手法を見つけたいのであれば、あなた自身がデータと向き合う以外の道は無い。 ただし、大まかな仕組み（あと多少のヒントも）だけは書いておくので、もしあなたが独力でデータ解析を行おうという気概のある人物なのであれば、この記事はあなたの助けとなるだろう。 ちなみに、これは前回の記事の続きなので、読んでない方はこちらからどうぞ。 stockedge.hatenablog.com オッズの歪みを探す さて、前回からの続きである。 前回の記事のブコメで「回収率を上げたいならオッズ

Register as a new user and use Qiita more conveniently You get articles that match your needsYou can efficiently read back useful informationYou can use dark themeWhat you can do with signing up

この記事は Ruby Advent Calendar 2015 の 8日目です。 比較的あまり知られていないと思うオススメの Ruby の機能を 7つ紹介します。 Enumerator.new Enumerator.new は知ってはいても、あまり使わない人が多いように思います。 私は非常によく使います。 理由は スコープを新たに導入したい Producer-Consumer パターン。値の生成と消費でフェーズの違いを明確化したい。 そのメソッド内で1度使いたいだけなのに yield するメソッドを別に作るのはちょっと気が引ける。名前空間を汚したくない。 全部、一度配列にしちゃうとメモリが気になる。メモリ消費を節約したい。 ネストを浅くしたい Enumerable モジュールの機能が欲しい といったところです。 たとえば下記のようなかんじで使います。 # Producer フェーズ use

日本国内でも随分使われるようになってきたSlack、みなさん随分使いこなしていると思うのですが、Slackも日々目まぐるしく進化してます。リリースを眺めたりするのが好きな筆者が「よく使う機能」や「これは便利だぞ」という機能を厳選して紹介します。 ※) 紹介しているのは、MacのクライアントAppを前提としています。 Slash Commands編 参照：Using slash commands – Slack Help Center みなさん、スラッシュコマンド使ってますか？ Slackでは殆どのことがスラッシュコマンドでできるといっても過言ではないくらい沢山のスラッシュコマンドがあります。ちょっと工夫すればオリジナルのスラッシュコマンドも作れるので楽しいですよ。 では、イチオシから紹介します１ リマインダー機能 たぶん、slackにリマインダー機能があることに気づいている人は少ないはず…