It’s way easier than you think. In my experience, you think you won’t need real-time functionality… until you do. Perhaps you want to add a chat feature, or simply sync data across users. At MuseFind, we have several Rails APIs, but none of them worked real-time. This led us to a pattern where we would reload data after sending in a change, keeping our front-end in sync with the back-end an often

Essential Go is a free book about Go programming language. It's part of Essential Programming Books. It's written to provide clear and concise explanation of topics for both beginner and advanced programmers. Most examples are linked to online playground that allows you to change the code and re-run it. You can also quickly navigate to desired content using table of content on the left and search

質問箱とかやっていると「こんなことがあって落ち込みます。どうしたらいいですか？」「メンタルが弱いのですぐに落ち込みます。」みたいなのが多くて、みんな落ち込んでいるんだなあ、と思った次第です。 かくいう僕も、メンタルが水気の多い豆腐くらい弱いのです。なんか老舗の旅館とかで出てくる豆腐みたいな感じです。あれおいしいよね。 なので、昔は落ち込んでる時が多かった気がするのですが、いろいろがんばった結果、落ち込むことがかなり少なくなり、落ち込んでも数時間でどうでもよくなるという感じになりました。 生まれ持った性質とかメンタルの強さではないので、他の人にも応用できるかなあ、と。というか、メンタルの強い弱いは、どちらかというと、物事に対してどう考えるかの習慣にすぎないんじゃないか、とも思っています。 というわけで、落ち込まないための工夫をちょっと紹介していきたいと思います。 (単に歳をとって気にしなくな

様々なサービスやプロダクトを開発してきた実体験をまとめるシリーズです。 後から考えればそうだったな。どうしてあの時は気づかなかった、もしくは意図せずやってたんだろうな、ということばかりで、また同じ間違いや無作為な開発をしないようにしようという自戒を込めています。 これらの自戒は去年、シリコンバレーやベルリン、深圳などに訪れ、異なる文化背景を持つ人たちの開発スタイルや物の考え方に触れたりすることである程度のまとまりを得ました。 ポイントはたくさんあるので、時間を見つけては少しずつ書いていこうと思います。 今回のテーマは、サービスやプロダクトが持つ20%と80%の役割分担（チームワーク）の話です。 ※この割合はサービス毎に違うかもしれません。 これはサービスが内包する機能の割合です よく最近、プロダクト・マネジメントを行う前段の準備として必要なことを解説するのにこんな表を使います。 プロダクト

Too Long; Didn't ReadShouldn’t state management be a solved problem by now? Intuitively, developers seem to know a hidden truth: state management seems harder than it needs to be. In this article, we’ll explore some questions you’ve probably been asking yourself: Shouldn’t state management be a solved problem by now? Intuitively, developers seem to know a hidden truth: state management seems harde

はじめに こんにちは。KitchHikeエンジニアの小川です。 Webアプリケーション開発において、コードベースが大きくなってくると、よく問題になるものの一つが表示ロジックの重複ではないでしょうか。知らず知らずのうちにビューに同じようなロジックが増えて、コードの見通しが悪くなってくるのです。 KitchHikeのコードにもその兆候が見られはじめたので、対策として ViewModel パターンを取り入れています。このパターンを適用することで、表示ロジックを集約し、コードのメンテナンス性を向上させることができました。 ViewModel は、そんなに凝ったことをしているわけではないのですが、コードをすっきりさせる上ではかなり強力なパターンです。 今回はこの ViewModel について、実際の使い方を含めご紹介したいと思います。 ViewModelとは? 一言でいえばビューに関連するロジックを

まずはサンプルクラスから始めましょう。 class SocialMediaPublisher def publish(social_media_type, user, message) social_media_api = nil case social_media_type when 'facebook' social_media_api = Facebook::API.new(user) when 'twitter' social_media_api = Twitter::API.new(user) when 'instagram' social_media_api = Instagram::API.new(user) else fail(InvalidSocialMediaType, social_media_type) end social_media_api.sign_in so

1. Effective Team Building 2018/2/24 オープンセミナー広島 株式会社アトラクタ取締役CTO アジャイルコーチ 吉羽龍太郎 @ryuzee 2. 株式会社アトラクタのご紹介 ✤ 開発プロセスに関するコンサルティングやトレーニングを提供 ✤ ✤ アジャイル開発 / DevOps / チーム育成 / クラウドコンピューティング / ドメインモデリングなどが専門領域 https://www.attractor.co.jp/ 3. 吉羽龍太郎 @ryuzee ✤ 株式会社アトラクタ取締役CTO/アジャイルコーチ ✤ 野村総合研究所、Amazon Web Servicesなどを経て創業 ✤ アジャイル開発/DevOps/クラウドのコンサルティングとトレーニングを提供

Ruby Business Users Conference 2018 2018-02-23 (Fri) 14:00 - 17:00 http://www.ruby.or.jp/rbuc2018/ https://rubyassociation.doorkeeper.jp/events/69247

こんにちは。もうそろそろ春ですね。 2月末日付で前の会社を退職し、3月1日付で新しい会社に移ります。 旧）プログラマー兼QAエンジニア 新）データサイエンティスト兼開発エンジニア となります。 IT業界に入ってから1年での転進となります。 会社に貢献し、技術者としても一層成長したいと思いますので、引き続きご指導ご鞭撻のほど、よろしくお願い申し上げます。 日記の内容 今回の日記では、どんな感じで転職活動をしたのかを書いていきたいと思います。何かの参考になりましたらうれしいです。 ※　主な対象は「IT業界内の転職活動に興味のある方」「未経験だけどIT業界で仕事がしたい方」「現在SESで働いているけれど脱出したい方」「異業種からIT業界を目指したい方」です。レベルの高い内容は出てこないと思いますので、ご寛恕いただけましたら幸いです。 ※　あくまで本人の実体験に基づく記事であり、本記事を利用するま

転職の決断は、ときに難しい決断になる。 WayUpのCEO兼共同創業者リズ・ウェッセル（Liz Wessel）はグーグルで2年働いたあと、その時が来たことに気づいた。 もし次のステップへの見通しが、あなたの気持ちを揺さぶっているなら、それは転職のサイン。 WayUpのCEO兼共同創業者のリズ・ウェッセルは、グーグルを辞めるべきときを知っていた。 結局のところ彼女は自分がやりたいことを探すために、2年で辞めるつもりでグーグルに入社した。2012年、グーグルに入社するときに、彼女は同社のリクルーターにも自分の計画を話している。 リクルーターは彼女の希望を認めた。2年後、彼女はグーグルを辞め、大学生と若いビジネスマン向けの就職支援サービス、WayUpを起業した。 だが、ウェッセルのような明確なプランを持っていないとしたら、いつ転職すべきときだと分かるだろうか？ どうすれば早まった決断や長く居すぎ

最近の立ち位置としてはライオンと一緒にされていまして、テストを書いていないプルリクエストとかに対して、却下の代わりにこの画像が張られるみたいな形で、一種の恫喝の代わりに使われています。 が、本人はきわめてジェントルな人で、いましゃべってるところを見て、このライオンとはキャラが違うなとお感じになっていただければ嬉しいです。 ついて行くべき変化とスルーしていい変化 昨今の技術の現場でよくあるのは、フロントエンド疲れ。JavaScriptの新しいフレームワークや、開発方法論とか、そういうのがどんどん登場して、また新しいものが出てきたと。 2年前に標準とされていたものがすっかり過去のものになってしまっていて、Gruntはどこに行ってしまったんだとか、Backbone.jsはどこに行ってしまったんだとか。 そうした変化に追いつけずに、疲れてしまうわけです。 かと思えば、一種の限界集落。よく言えば安定

初演: 2018/02/15 デブサミ2018 15-D-1 ハッシュタグ: #devsumi #devsumiD https://togetter.com/li/1199564

Hacker Tackle 2018 発表資料

by jarito 「アイデアが何も思いつかない……」という悩みもありますが、反対に「やりたいことのアイデアがありすぎて困る！」という悩みもあります。そんなときは「このアイデアを選び、代わりにあのアイデアは捨てる」という選択が必要になりますが、「選択の際に重要な『アイデアの価値』を知るにはどうしたらいいのか？」という問題についてソフトウェアエンジニアのトミー・ウォルシュさんが説明した記事が、Indie Hackersに掲載されています。 How To Know If An Idea Is Worth Pursuing – thwiv – Indie Hackers https://www.indiehackers.com/@thwiv/how-to-know-if-an-idea-is-worth-pursuing-75501f81ad トミーさんはここしばらく、ありとあらゆるアイデアがT

はじめに 時の経つのは早いもので、私がIT業界に身を置いて四半世紀になってしまいました。 その間、膨大な数の「設計書（仕様書）」を書いて来ましたが、未だに悩み・迷いは尽きません。 それでも、亀の甲より年の劫とも申しますので、私なりの経験則を「個人」と「チーム」の両観点でまとめてみました。 本稿のテーマは、「主に設計書を想定した、開発ドキュメントの書き方」です。 本稿で前提とする設計書は、ExcelやWordで書かれた、フォーマルな（≒納品物になりえる）設計文書、です。 したがって、自社サービス開発よりも受託開発、アジャイルよりもウォーターフォール、を前提として読んでいただいた方が、しっくりくると思われます。 ＜ご注意＞ 本稿の内容は執筆者独自の見解であり、所属企業における立場、戦略、意見を代表するものではありません。 個人的に心がけていること 当該文書の作成目的や位置付けを冒頭に記載する

【翻訳】サイドプロジェクトから収益性のあるスタートアップに育てる方法（前編）Feb 14, 2018 個人開発論翻訳この記事は、Pieter Levels(@levelsio)の「Turning side projects into profitable startups」という記事を、本人の許諾を得て翻訳・掲載しているものです。 ※原文記事はこちらからご覧いただけます。 もし翻訳に間違いなど見つけた方は、info[at]notsobad.jpまでご連絡いただけるとうれしいです。 （訳注）元の記事と著者について@levelsioってどんな人？オランダ出身の「Serial Maker（連続していろんなプロダクトを作る人）」。 代表作は、世界中の都市のノマド向け情報をまとめた「Nomad List」など。 個人でユニークなサービスを開発・運営して収益を上げており、Product HuntのMa

A few hours after this morning’s big unveil, Humane opened its doors to a handful of press. Located in a nondescript building in San Francisco’s SoMa neighborhood, the office is home to the startu

コンサルタントをやっていた頃、良いか悪いかは別として、採用に関して「地頭の良さ」を重視する風潮があった。 地頭の良い人間は一定の訓練でそれなりのコンサルタントになる。 だが、お世辞にも地頭の良いとはいえない人間は、いつまでたっても一人前になれなかったからだ。 実際、私が20代半ばで所属していた部署では、中途採用にあたって「学歴」をさほど重視していなかった。 重視していたのはとにかく「地頭」だ。 ある応募者は、「高卒」で「自動車整備工」になり、そして「先物取引の営業」に転職、そして最後に「漁師」という経歴を持っていたが、彼は採用された。 彼の言動は、地頭の良さを十分に感じるものであったからだ。 彼の業務経験の貧しさは訓練でなんとかなる、皆がそう思ったのである。 彼はその後、会社に大きな貢献を残し「支社長」まで努めたのだから、その時の判断は間違っていなかった。 ■ この「地頭」の正体について、