エンジニアが会社を選ぶ時代へ | AbemaTV
※ヘッダー画像は「iOSDC Japan 2016」のジョブボードに掲載したポスター 先週末開催されたiOS関連の技術カンファレンス「iOSDC Japan 2016」の懇親会にてLTを実施してきました。 このLTの内容を掘り下げてまとめてみたいと思います。 大手なのに自由？エンジニアの裁量権この数ヶ月採用活動をしている中で、たくさんの優秀なエンジニアと話をする機会がありました。 そんな彼らと話をする中で、企業選びで大事にしているポイントが自分なりに整理することができました。 「挑戦」 ： エンジニアの成長に不可欠な技術的な挑戦ができるか？ 「仲間」 ： 優れたエンジニアと切磋琢磨できるか？ 「評価」 ： 納得できる評価と報酬が提供されているか？ 「やりがい」： 仕事にやりがいを感じられるか？ 「環境」 ： 最高のパフォーマンスを発揮できる環境が整っているか？ この中でも「挑戦」を
Raspberry PiとSoracom AirでSMSの送受信
Raspberry PiとSoracom Airを利用してSMSを送る方法について紹介しています。 あとがきに書いた通り、SMSは普通に（インターネットを使わずに）送っています。 まず、これを作ってみた理由ですが、実をいうと今年のお盆に実家に居た時に、東京にある事務所のインターネット接続ができなくなるという問題が起きまして、その事務所にRaspberry Piを置いておき、定期的なインターネット通信の確認や、問題発生時にルーターの再起動をやらせよう、という考えが浮かびました。その通知や命令は手元の携帯でできるようにしたかったので、SMSを使ってみることにしたというわけです。 このRaspberry Piは、ネットが繋がらなくなるとSMSで「止まってるかもよ」と教えてくれて、「再起動して」とお願いするとしてくれます。あと「生きてる？」と聞くと「はい。生きてます。」と答えてくれるようにしました
オブジェクト指向設計実践ガイド ～Rubyでわかる 進化しつづける柔軟なアプリケーションの育て方
2016年9月2日紙版発売 2016年9月2日電子版発売 Sandi Metz 著，髙山泰基 訳 B5変形判／304ページ 定価3,608円（本体3,280円＋税10%） ISBN 978-4-7741-8361-9 Gihyo Direct Amazon 楽天ブックス ヨドバシ.com 電子版 Gihyo Digital Publishing Amazon Kindle ブックライブ 楽天kobo honto 本書のサポートページサンプルファイルのダウンロードや正誤表など この本の概要 オブジェクト指向設計の名著として名高い“Practical Object-Oriented Design in Ruby”，待望の翻訳版！使いこなせるようになるととても便利なオブジェクト指向ですが，「なんとなく」の理解で使っていると，大きな罠にかかってしまいます。本書は，保守性を上げて運用コストを下げるア
英語はたった｢20の動詞｣でぐっと上達する
コンテンツブロックが有効であることを検知しました。 このサイトを利用するには、コンテンツブロック機能（広告ブロック機能を持つ拡張機能等）を無効にしてページを再読み込みしてください。 ✕
【書評】SOFT SKILLSを読んでプログラマとしてのキャリア設計を見直そう - give IT a try
（2022.3.17追記）第2版が出版されたので、こちらで第2版の書評を公開しています。 blog.jnito.com 以下は第1版の書評です。 はじめに 先日、最近ネットでちょくちょく名前を見かける「SOFT SKILLS」という本を読み終わりました。 SOFT SKILLS ソフトウェア開発者の人生マニュアル 作者:ジョン・ソンメズ日経BPAmazon Amazonのレビューを見てるとなんか冷めた意見が多くて「イマイチなのかな？」と思ったんですが、実際読んでみると全然そんなことはなく、「これは面白い！」と思える久々のヒット作でした。 半分くらい読んだけど、かなり面白い。 Read a half of book, very very interesting. @jsonmez pic.twitter.com/ZhLE3BRmhs— Junichi Ito (伊藤淳一) (@jnchito
サーバからクライアントに送信する技術 - WebSocketを中心に - Qiita
Webでのプッシュ技術 HTTPはクライアント（ブラウザ）からリクエストしてサーバからレスポンスが返る一問一答型のプロトコルなので、基本的にはサーバ側からブラウザに新着情報をリアルタイムで通知（プッシュ）できるようにはできていません。 しかしそれでもプッシュをしたいという場合にどうするかという話が出てきます。やり方には以下のようなものがあります。 ポーリング クライアントからサーバに定期的に新着を問い合わせるようにします。 最も原始的かつ確実なやり方。欠点は、最大でポーリング間隔の分だけ通知が遅延しうることです。 ロングポーリング（“COMET”） ポーリングなのですが、問い合わせを受けたサーバは新着情報がなければレスポンスを返すのをしばらく保留します。 そのあいだに新着情報が発生すれば即座にレスポンスを返しますし、一定時間経過したら何もなかったとレスポンスを返しましょう。 飛び交う通信内
フロントエンドでみた、情報系ブログとはてブの地獄メカニズム - エモくありたい
ブログ以外での活動をみていただければ理解いただけるかと思うが、私は普段はフロントエンドの界隈にいる。 そのなかで、ちかごろ界隈のインターネットが非常につらいと感じることが多々ある。 他の界隈でもそれなりは見られるが、特にフロントエンドで顕著にみられるその「つらい」傾向を完結にまとめてみた。 フロントエンド地獄インターネットのメカニズム 現状のフロントエンドをみていて複雑な気持ちになるパターンはおおよそ以下である。 全体的な地獄フロー 何かしら新しい技術が出てくる Qiitaはてブロ辺りでイケハヤみたいなタイトルの技術系エントリが投稿される バズる 使ってもいない人間がニコニコ動画のコメントみたいな発言をする 地獄になる 誰しもこういう流れをみたことはあるだろう。本当に複雑な気持ちになる人間が多いであろうと思っているため、この「気持ち悪さ」の何が悪いか、どうして起きるのかを自分なりにまとめて
sidekiqのリトライ回数は26回以上を指定できる - PartyIX
Railsの非同期処理実行を実現するgemとして，sidekiqは非常に有用です． 有名ではあるので，一般的な使い方についてはここでは説明しません． Rails - sidekiqの使い方 - Qiita この辺を見ると簡単に使えるようになると思います． リトライについて sidekiqに任せる処理に，エラーを含むような処理を実装すると，エラーにより処理が中断された後，sidekiqが自動でリトライをしてくれます． ただ，そのリトライ回数は，無限ではありません． デフォルトの設定のまま class TestWorker include Sidekiq::Worker def perform(*args) raise end end こんな処理を書いておくと，sidekiqは25回までリトライをしてくれます． しかし26回目はなく，その後DeadJob（死亡）に振り分けられ，以降リトライされ
そして物語は何度目かのアプリ内通知再実装を迎える - その手の平は尻もつかめるさ
というタイトルでKyoto.なんか #2で発表してきました． そして物語は何度目かのアプリ内通知再実装を迎える / Reimplement in app notification // Speaker Deck スライドの内容としては，アプリ内通知 (Twitter appで言うところの「通知」タブにあたる部分) のサーバサイドを実装する際にどういう問題があって，それをどういう風に実装したかという葛藤の記録となっています． Webアプリケーションやスマートフォンアプリケーションを書いていると，そこそこの確率でアプリ内通知を書くことになると思うんですが，ところがどっこい「実際にどういう風に実装しているか」みたいな知見が共有されている感じがあまりありません．みんな実装しているはずなのに，ググってもあまり情報が出てこなくて寂しい．地味な機能だから？ という思いがあり，そこら辺アプリ内通知周辺の技
ご契約について – モンキーレンチ
ご契約の流れFlow 1.お問い合わせ まずはメールフォームから、目的や内容、ご予算等をお聞かせください。 2.お打ち合わせ・ヒアリング メール・Facebook、ご面談等でより具体的な内容やご希望スケジュール等をお聞かせください。 3.お見積 お打ち合わせの内容をもとにお見積を作成し、メールにて送付いたしますのでご検討ください。 4.ご契約・発注 お見積にご了承いたけましたら契約書を作成いたします。契約書に双方捺印のうえ、それぞれ1通ずつ保管、ご発注書をお送りいただき、着手金のお振り込みが確認できましたら制作を進めさせていただきます。 「サポートサービス」の場合は、着手金は不要です。 ご契約内容についてAbout contract Web 制作をご依頼いただいた場合、制作に入る前に必ずご契約書の締結をお願いしております。 一般的に、小額の案件においては簡略化のためにご契約書無しで発注、制
GitHubのmasterブランチをWebページとして公開する手順（GitHub Pages） - Qiita
GitHubでは、サーバーを自前で準備しなくてもWebページを公開できる「GitHub Pages」という機能があります。これまでは、gh-pagesという別ブランチを作成して、そこにソースコードをプッシュする必要がありました。しかし、本日(2016/08/18)実装された新機能により、masterブランチのみでWebページを公開できるようになりました。 本エントリーでは、具体的な設定手順を紹介します。 手順 masterブランチにて、「docs」フォルダーを作成します。このフォルダーに公開したいWebページのソースコードを入れます。 masterブランチをプッシュします。 GitHubのリポジトリページ上で、[Setting]→[Pages]に移動します。 [Source]の箇所から、「Branch: main」、「/docs」フォルダーを指定します。 [Save]を押すと、下図の赤枠部
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
