SREチームを発足しました - SmartHR Tech Blog
いよいよfreeeの開発チームブログが始まりました。初回を任されましたエンジニアの米川(@yonekawa)です。 記念すべき最初の記事ということで何を書こうかと考えたのですが、開設つながりで会社設立 freeeの話をしようと思います。 会社設立 freeeは「会社設立に必要な書類が5分で作成可能」なサービスで、リリースされてから現在までに3,000社以上の企業がこのサービスを利用して法人登記されています*1 順調に成長していると言える会社設立 freeeは、1年半ほど前にPM・ビジネス・UX・エンジニアの4人のチームで開発されました。 エンジニアは僕だけで、rails new してからリリースに至るまでの全てのコードを1人で書いていました。 そんな限られたリソースの中でプロジェクトを成功させるために、当時の僕たちが大事にした3つのプラクティスについて紹介します。これらのプラクティスは現在
「Front-End Developer Handbook 2017」がGitBookで無償公開。フロントエンドデベロッパーに求められるさまざまなスキル、要素技術、ツールなどを幅広く紹介する一冊 WebサイトやWebアプリケーションにおいて、ユーザーが操作する部分の開発を担う「フロントエンドデベロッパー」が扱う技術は急速に広がっています。 もちろんその基盤はHTML/CSS/JavaScriptにありますが、より高度で快適なユーザー体験を実現するにはその基盤となるHTTPやDNSといった下位レイヤの技術やSEOやUIデザイン、フォントといった細分化された専門性、そしてもちろんJavaScriptプログラミングやjQuery、React、Angularといったフレームワーク、JSONやAPIやパッケージマネージャ、ビルドツール、エディタやデバッガなどの周辺ツールとそのトレンドなど、とても一人
前回に続いてまたAuroraです、Aurora。高い可用性なのはわかっていますが、じゃあ具体的にどのくらいやねん、となると良い情報がなかったので調べることにしました。 Auroraの公式情報は、一定以上の知識を前提とした内容になっていて、良いバランスで心地よい感じなのですが、まだ読んでて楽しいコンテンツが欠けている印象です。一般情報も、出ました、使ってみました、とかしか無くて寂しいので、ブルーオーシャンを泳いでいくとしましょう。 AuroraのEndpoint 公式読めばいい所なので軽く復習ですが、現在のAuroraのEndpointは3種類あります。 Cluster Endpoint … 常にWriterを指すFQDN。参照更新の両用 Reader Endpoint … ランダムでReaderを返すFQDN。参照用 (Instance) Endpoint … インスタンス毎に割り当てられ
こんにちは。卜部です。最近のPython-devが始まりましたね。すごい。 こちらの連載は先月はお休みしてしまったのですが、引き続き頑張ります。 ruby-coreというRuby本体の開発の議論がされているメーリングリストで、最近興味深かったトピックを紹介していきます。 最近のruby-core (2016年11月) 最近のruby-core (2016年10月) 最近のruby-core (2016年9月) 最近のruby-core (2016年7月) 最近のruby-core (2016年6月) 最近のruby-core (2016年4月) 最近のruby-core (2016年3月) 最近のruby-core (2016年2月) [#12852] URI.parse can't handle non-ascii URIs Railsがよく ?utf8=✓ とかいうクエリをつけてきます
娘がパソコン好きそうなので子供用パソコンを作ろうと思った 娘が最近自分の真似をしているのか、USBキーボードをいじって遊ぶようになりました。 View this post on Instagram A post shared by karaage (@karaage) View this post on Instagram A post shared by karaage (@karaage) 今のところはそれで満足しているのですが、自分のパソコンとの違いに気づく日も早そうなので、今のうちに娘用のパソコンを家で余っていたRaspberry Piを使ってセットアップしてみることにしました。プログラミング教育も義務化することですし、パソコンに触れるのは早いのに越したことはないと思っています。 子供用パソコンをRaspberry PiとKano OSでセットアップする方法 Kano PCという子
2016年5月ごろからbizoceanのデータ集計、解析プロジェクトにDockerを使いはじめ、本番環境にはGoogke Container Engineを使っている。 使ってみて、今後コンテナ技術はどんどん普及していくなと確信した。 利用の有無は、開発スピード、サーバーのコスト、メンテナンス費用など競争力に大きな差がつくと思う。 まだ使い始めて3か月もたっていないが、今後普及すると思っている根拠と、その良さをまとめてみようと思う。 Googleでの普及 Googleは言わずもがな、世界一ともいえるコンピューティング技術とインフラを持った企業だ。 Googleにおいてはデーターセンターの管理をしているBorgからコンテナ運用の実績があり、それをいかしてGKEのベースであるKubernetesの開発も行っている。 Dockerに使われているCgroupsももともとGoogleが開発したものら
パターン AWS のマネージドを中心に CI / CD パイプラインを組むなら ECS ElasticBeanstalk CodeDeploy Docker for AWS を用途に応じて使い分けられます。 用途 自分でクラスタを管理したい / しなければならないといった特別な理由がなければ、ECS がオススメです。最近 Datadog も ECS の本番利用が増加していることを記事1にしています。 メリット コンピュートリソースを最大限有効に利用できる ALB との併用で動的ポートマッピングが有効に Service Auto Scaling でスケールも AWS に任せられる タスク単位で IAM ロールを使った適切な権限管理ができる Spot fleet 上での運用でコスト最適化も CloudWatch でクラスタとしてのメトリクスも扱える 構成例 継続的デプロイ例 ElasticBe
Speeeエンジニアブログをリニューアルしました! これまで「TECHNICA」というタイトルでブログを運営してきましたが、「Speee DEVELOPER BLOG」に名前が変わります。今後とも宜しくお願いします! というわけでここからは、医療関連のエンジニアをしている西岡(nisshiee)から本題です。 Speeeの社内勉強会 最近、Speeeラウンジで開催した勉強会やイベントのご報告をたくさんさせていただいていますが、今日は社内で行われている勉強会の話をしたいと思います。 現在、Speeeの社内勉強会は大きく分けて2つあります。 1つは、毎週定例で開催している勉強会で、「エンジニア全体MTG」と呼ばれています(特に名前に意味はないです)。社員エンジニアは全員参加で、業務委託など別の形でお手伝いいただいているエンジニアやエンジニア以外の職種のメンバーにも自由に参加してもらえるようにし
フラットカッターミル 平行に並んだ固定刃と回転刃が、豆を一粒ずつ挟んでゆっくりと挽きます。摩擦熱が少ないので、豆の香りを損ないません。 87℃の温度管理 抽出するお湯温度が高いと苦味が強く出やすいため、酸味と苦味など味のバランスと豆本来の香りを引き出すのに最適な「87℃」で温度を管理しています。
はじめに 昨年末に初めてAWS Lambda 環境でLINE Bot を開発しました。 簡単なBot を作るだけであれば、Lambda を素で使っても問題ありませんが、LINE Login など他のWEB サービスからの呼び出しを受け付けて動くような少し複雑なBot を作ろうと思うと、ちょっと辛くなってきます。 Lambda 環境でNode.js のexpress のようなフレームワークが使えないかと思って検索していると、こちらの記事を見つけました。 AWS 謹製 aws-serverless-express を使って APIGateway + Lambda + Node + Express で RESTful サービスの雛形を最速で作る 記事によると、Lambda でexpress が使えるコードがAWS 公式で(!)提供されているとドンピシャの内容でしたので、そうならば使ってみるしかあ
PHP勉強会#110での発表資料です。
みなさんこんにちわ。 メドピアでエンジニアをやっている内田と申します。 現在メドピアではPHPで作られたレガシーな独自フレームワーク (以下FW) からRailsへと移行するプロジェクトが進んでいます。 今回は移行に向けて行ったことについて共有したいと思います。 移行の計画 メドピア株式会社では、医師限定のコミュニティサイト「MedPeer 」を運営しています。 「MedPeer 」サービス内では、薬剤評価掲示版、症例相談、Forum、ニュースなど、医師同士が情報交換をするための、機能の異なる複数のサービスを提供しています。 それらサービスの内部では7年前に作られたPHPの独自FWが採用されており、コードが肥大化したことで機能の変更や追加がとても困難になっていたことが課題でした。 そうした課題を解決するために、アーキテクチャの見直しを含めたリプレースがエンジニアの主導で計画されました。 様
ブロックチェーン技術について説明する記事を書いていると、次のような意見を耳にすることがあります。「ブロックチェーン技術を使わずにデータベース管理システムを使えばいいのでは?」──主にITに詳しい人からこの意見が出る場合が多いようです。 筆者の個人的な意見としては、ブロックチェーン技術とデータベース管理システム(DBMS)やKVS(Key-Value Store)は目的も特性も異なる技術なので「別のもの」と考えた方が理解が早いと思います。それ以前に「そもそも、ブロックチェーンとデータベースを比べること自体が間違っている」とのご指摘もあろうかと思います。 現実に、ブロックチェーンの説明で「データベース」という用語を使う事例はいくつかあります。「ダボス会議」で知られている世界経済フォーラムによる解説動画では、パブリックブロックチェーンについて「オープンで脱・中央集権的なデータベース」と説明してい
ノハナの中の様子を時に真面目に時にゆるゆるとお伝えします ノハナで主にサーバーサイドを担当しているエンジニアの武市 (@tacke_jp) です。 Parse.comが1年後にサービスを終了することをアナウンスしたのが2016年の1月28日 。それから約1年が経った本日未明にParse.comは完全にサービスを終了しました。これまでノハナを支えてくれたParse.comに感謝を述べつつ、ノハナがParse.comと共に過ごした4年間を振り返りたいと思います (※1)。 Parse.comとノハナ ノハナがサービスインしたのは2013年の2月13日でした。サービスの立ち上げ時からParse.comをフル活用していたため、そこから考えると約4年間Parse.comを使っていたことになります(※2)。 利用していた機能は多岐にわたり、データベースはもちろんのことユーザー認証やプッシュ通知、さらに
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く