トップへ戻る
カレーが食べたい
blog.agile.esm.co.jp
9月に中途で入社した@wat-aroです. 前職はプログミングと全く関係のない仕事でしたが,プログラムを書く仕事がしたくて退職しました. 退職してからはまず基礎を身につけようとSICPを読み,ほとんどの問題を解き終わったのでFjrodのリモートインターンに参加して勉強していました. 今日は永和システムマネジメントの技術面接で出されたアルゴリズムの問題を紹介しようと思います. 出された問題はアナグラムの判定です. アナグラムとは文字列の順番を入れかえて,別の文字列になっているものです. eros と rose は文字の順番を入れ替えているだけなのでアナグラムです. eros と lose は文字を入れ替えただけでは一致しないのでアナグラムではありません. これを判定するコードを書きます. 面接ではRubyで書くのが難しければ疑似コードでもいいし,口頭でアルゴリズムを説明するだけでもいいと言わ
こんにちは、hibariya です。さいきん GraphQL でのファイルアップロード方法について知りたいなと思いちょっと検索してみたところ、すぐにはこれといった方法に辿りつけなかったので気になって調べました。手元で試した感じだと GraphQL multipart request specification という仕様が良さそうでしたので、今日はそのことについて紹介したいと思います。 GraphQL でのファイルアップロードはめんどう 現在のところ、GraphQL の仕様ではファイルアップロード方法については特に規定されていないため、自分たちで方法を決めて実装する必要があります。が、これは少し面倒です。HTTP で GraphQL を使う場合、サーバに渡す値はたいてい JSON のようなフォーマットでシリアライズしますが、FileオブジェクトはそのままJSONにはエンコードできません。
@koic です。 運用上の作業を開発者が行うというのは、昨今の DevOps ではよく見る光景だと思います。そして、運用手順の実施などにおいてダブルチェックというものを聞いたことあるでしょう。いや、むしろプロジェクトのルールで必要とされ、聞いたことがあるというレベルではないケースもあると思います。 そんなダブルチェック文化について、個人的には「ダブルチェックと聞いたらまず必要性を疑って判断する」という立ち位置で、本稿はそういった音楽性の人が書いた記事となります。 なお、一口に「ダブルチェック」といっても定義は広いため、「リアルタイムでの2人以上の指差し確認」を本稿でのダブルチェックの定義として位置付けます。 そもそも人間は間違えうるもの 本番環境へのショートサーキット 👿 Ops でも Dev のレビューフローにする 👼 形骸化したただの着席プロセスになっていないか疑う そもそも人間
こんにちは、富山在住の kunitoo です。 リモート勤務はじめましたにもありますが、昨年12月20日から出身地である富山県に引っ越し、リモート勤務という体制で働き始めました。 約10ヶ月間リモート勤務を行なった感想は、スムーズにリモート勤務に移行でき、 日々の業務も問題なく進めていけたと感じています。 リモート勤務を実施する中で、事前にやってよかったことや工夫してみてよかったことについてまとめました。 リモート勤務をこれから始める人や、既に実施している人の参考になればと思います。 よかったこと リモート勤務をはじめる前から東京での在宅勤務が定着していた プロジェクトを変えずにリモートに移った マイクスピーカーを拠点ごとに用意した Idobata 等の通知にすぐに反応できるようにした ビデオチャットを気軽に接続できるようにした 家族に「いってきます」「ただいま」を言うようにした リモート
こんにちは。wat-aro です。 Docker 環境で開発する際に VSCode の Remote Container はとても便利ですね。 でも今まで Emacs で開発してきた人は VSCode ではなく Emacs を使いたいはずです。 ここでは僕が Emacs + Docker 環境でどのように開発しているかを紹介します。 docker コマンド まずは docker コマンドを使えなくてはなりません。 Emacs 使いのみなさんはターミナルでなく Emacs から docker コマンドを叩きたいですよね。 そんなときは docker.el です。 https://github.com/Silex/docker.el docker image コマンドや docker compose コマンドが Emacs から実行できます。 docker compose up で立ち上げたコ
こんにちは、hibariya です。最近 ミートアップ が開催されるなど、GraphQL が静かに注目を集めていますね。GraphQL は Web API で使えるクエリ言語です。GraphQL 自体は特定のデータベースに依存しないため、RDBMS を使ったアプリケーションで採用することも可能です。PostgreSQL を使う Idobata でも GraphQL の Public API を公開しました。GraphQL 自体がどういうものかについては、graphql.org や以下の資料が参考になるのではないかと思います。 GraphQL APIをRailsアプリに実装した時のメモ GraphQL勉強会 2017.6.7 (補足) Building a Web API with GraphQL GraphQL でサーバ側を実装するときに起こりがちな問題として、クライアントから投げられるク
最近の趣味はもっぱら L7 より下のお勉強、な @yucao24hours です。 梅雨入りもどこ吹く風の暑いある日、いつものように git pull を実行すると、以下のような警告が出るようになりました。 $ git pull warning: Pulling without specifying how to reconcile divergent branches is discouraged. You can squelch this message by running one of the following commands sometime before your next pull: git config pull.rebase false # merge (the default strategy) git config pull.rebase true # rebas
こんにちは、hibariya です。npm と互換性のある新しいパッケージマネージャ Yarn が話題ですね。idobata.io でも npm の代わりに Yarn を使うようになり、CI やデプロイが数十秒早くなりました。 今日は Yarn を試すなかで気になったポイントをまとめてみます。なお、これを書いている時点で既に 0.16.0 と 0.16.1 がリリースされ、既に解決したものもあります。ぜひ最新版へアップデートしましょう。 yarn run のスペースの扱い 0.15.1 までは、スペースを含めてコマンドの一部として扱われてしまうようで、オプションや引数を渡す使い方ができませんでした。そのため package.json に以下のような scripts を用意して yarn run で実行すると失敗していました。 "scripts": { "build": "ember bui
2004年中途入社の koic です。来月で入社17年。長いですね。 17年の間で人や技術が流転する長い勤務の中で伝承の途切れを観測していることから、私がいまの勤務先に入ったころ Wiki への考え方への影響を受けたものを発掘してみました。今回、私的解釈を交えて一般公開します。 はじめに 『ドキュメント記述の心構え』原文 私的解釈 {{toc}} 木構造よりも、ネットワーク構造を好め ネストしたリストよりも、見出しによる構造化を好め リストで文章を区切るよりも、空行をあけてPタグでレンダリングせよ 安易に項目追加する前に、リオーガナイズを検討せよ 正規化と重複の均衡点を探せ PREとQUOTEを使い分けよ リオーガナイズのメカニクスを用意せよ おわりに はじめに 本記事で取りあげるのは 2006年以前に「ドキュメント記述の心構え」 (WikiName は DeciplinesOfWriti
エンジニアリングマネージャーの @koic です。富山Ruby会議01の主催者でもあった @mugi_uno さんがまとめられたリモートワークスタイルチェックを行ってみました。 ここ最近やった何件かのカジュアル面談を通して、"リモートワーク" のスタイルの認識に企業・個人によって大きく差がある印象を受けたので、ミスマッチを防ぐためにチェックリスト的なものを作ってみました(こういう観点もあるよ〜とかあれば知りたい)https://t.co/1faTEwNzKB— mugi (@mugi_uno) 2022年3月22日 受託開発企業である弊社アジャイル事業部でのリモートワークのチェックリストとなります。サービス企業でない受託開発企業の、ひとつのリモートワーク度合いとしてご参考ください。それでは見ていきましょう。 リモートワーク比重度 リモートワークの導入期間 どの程度リモートワークを導入してい
こんにちは、平田です。 少し前の話になりますが、AgileJapan2017と、翌日に開催されたモダンアジャイルワークショップに参加してきました。 www.agilejapan.org agilejapan.org モダンアジャイルについて アジャイルソフトウェア開発宣言が出されてから15年以上が経ち、その現代的な解釈を「モダンアジャイル」として Joshua Kerievsky さんがまとめました。 モダンアジャイルの4つの原則は以下の通りです。 Make people awesome(人々を最高に輝かせる) Make safety a prerequisite(安全を必須条件にする) Experiment and learn rapidly(高速に実験&学習する) Deliver value continuously(継続的に価値を届ける) それぞれの内容については、いろいろなブログ記
みなさんこんにちは!今年 8 月をもって無事に永和 4 年生に上がった @yucao24hours です。 多彩なご経験とパワフルな「デブオプス!!!!!」の掛け声で有名な(?)牛尾剛さんをお呼びした社内勉強会が、8 月 26 日(金) に弊社にて開催されました。 牛尾さんといえば... わたしは Agile Japan 2016 ではじめて牛尾さんの講演を直接聴き、そのインパクトの大きさと感動を自分のブログにぶつけていた過去があります。 Agile Japan 2016 に参加してきた #agilejapan | 走る http://www.yucao24hours.me/2016/06/02/agile-japan-2016-report/ そんなわけで今回の勉強会は本当に楽しみで、勉強会直前に会社のエントランスで牛尾さんと鉢合わせたときは一瞬頭が停止してしまったほどでした。 「今日の
イベントで配布するノベルティとして、オリジナルのプランニングポーカーデッキを作成しました。 RubyKaigi 2018のスポンサーブースで配布したので、すでに持っている方もいるかもしれません。 11/1, 2 に開催されるRubyWorld Conference 2018のスポンサーブースでもお配りいたします。 参加される方はぜひお立ちよりください。 今回は私たちが作成したプランニングポーカーデッキについて紹介します。 プランニングポーカーとは プランニングポーカーはチームでユーザーストーリーなどを見積りを行うための方法です。 プランニングポーカーを使いチームで見積ることにより、チームメンバーでストーリーに対して議論することにより、 各メンバー間でどこまで何を行うストーリーなのか、やるべき事や落とし穴がないかなどの認識を合わせることを目的としています。 作成したプランニングポーカーデッキ
RuboCop や Active Record Oracle enhanced adapter などの OSS コミッターをやっているコミュニティマネージャの @koic です。 2018年11月13日(火) から 2018年11月15日(木) の間、カルフォルニア州のロサンゼルスで開催された RubyConf 2018 に行きました。 rubyconf.org 渡航までの準備については、個人の日記の方に書いているのでそちらを参照してください。 今回参加した動機は RailsConf 2019 に向けた渡米の経験を積むのと、RubyConf といった古くからの Ruby カンファレンスの雰囲気を知るといったものでした。 カンファレンス ここ最近の RubyKaigi への参加のモチベーションと同じくトークもさることながら、GitHub 上での OSS 開発でやりとりしている開発者とのオフ会
こんにちは。永和システムマネジメントの内角低め担当、はたけやまたかし( @htkymtks )です。 Amazon Dash Button に触発されて「勤怠ボタン」をつくってみたのでご紹介します。(↓こんなのです) Amazon Dash Buttonに触発されて、Wi-Fiにつなげる小さなマイコンESPr Developerで勤怠ボタンを作ったよ。在宅作業開始時に🏠ボタンを、作業終了時に🔚を押します。 pic.twitter.com/4GUOM1RyBe— はたけやまたかし (@htkymtks) December 9, 2016 勤怠ボタンとは? 私の所属する永和システムマネジメントでは在宅勤務が認められています。部署ごとに在宅勤務の運用ルールは異なりますが、私の所属するアジャイル事業部では在宅勤務時の作業開始と終了の連絡を社内チャットツール「Idobata」 *1 へ投稿するル
こんばんは。 @hrysd です。 弊事業部には @takkanm が管理しているアカウントリストというスプレッドシートがあります。 これには、メンバーが各サービスで使用しているアカウント名等が集約されていて新しいメンバーが増えた時なんかに更新されています。 スプレッドシートどこにあるの問題 スプレッドシートの URL を覚えていないので、どこにあるのか全く見当がつかないという理由から、 日常的に使用している esa.io に貼り付てみました。 これだとスプレッドシートの内容で検索する事が出来ないため、Google Apps Script を使用してスプレッドシートの中身と記事の更新を連動させたいと思います。 Google Apps Script を書く スプレッドシートを開きツールバーの ツール > スクリプト エディタ を開く事で Web 上から編集を行う事も出来ますが、npm のモジ
もう来週は、RubyKaigi2018ですね。 今年は弊社から、18 名のメンバーが参加します。 RubyKaigi に各メンバーが様々な関わり方をするので、この記事ではそれをまとめていきたいと思います。 RubyKaigi 二日目に @koic こと伊藤 浩一が登壇します まずは、スピーカーとしての参加です。 @koic が二日目の 13:00 より会場 Hagi にて、Improve Ruby coding style rules and Lintを発表します。 プロジェクトでのコードレビューや Ruby / Rails の変更点などから得た知見を、コーディングスタイルや Linter として RuboCop に還元していくという話です。 RuboCop を使っている方は、どうやって RuboCop が改善されていっているのかを是非その目で確認してください。 RubyKaigi の当日
こんにちは。永和システムマネジメントの内角低め担当、はたけやまです。 作成したプログラムが想定していた速度で動かず困ってしまうこと、ありますよね? パフォーマンス改善を行う場合、プロファイラなどを使ってプログラムを計測し、どこがパフォーマンスのボトルネックとなっているかを見つけることが重要です。 Ruby プログラムをプロファイリングするための方法はいくつかありますが、今回は stackprof を使った方法をご紹介します。 stackprof https://github.com/tmm1/stackprof stackprof を使ったプロファイリングは以下の手順で行います。 計測対象のプログラムに stackprof を仕込む 計測対象のプログラムを実行する 計測結果からボトルネックを割り出す 計測対象となるプログラム 今回は例題として以下のライフゲームを計測してみます。 lifeg
Rails / OSS パッチ会を2018年9月12日(水)に開催します。 この会をひとことでいうと、日頃のお仕事で使っている Rails をはじめとする OSS への upstream にパッチを送る会です。 会には Ruby と Rails のコミッターである顧問の a_matsuda もいますので、例えば Rails に送るパッチのネタがあるけれど、パッチを送るに適しているかの判断やパッチを送る流れが悩ましいときなど a_matsuda に相談して足がかりにするなどできます。 開催時間は 17:00-19:00 となりますがご都合のあう方はぜひご参加下さい。特に募集ページなど設けませんので、興味のある方は永和システムマネジメントの神田オフィスまでお越し下さい。 agile.esm.co.jp 終わった後は有志で懇親会などあるかもしれません。
終了して 2 ヶ月たってしまいましたが、5/31 - 6/2 に開催された、RubyKaigi 2018 に 3 名の学生を招待しました。 https://esminc.doorkeeper.jp/events/73118 招待の内容としては、以下の費用を補助するというものでした。 RubyKaigi 本編の参加チケット RubyKaigi 公式パーティーの参加チケット RubyKaigi 会場までの往復の交通費 RubyKaigi の開催期間の宿泊代(前泊、後泊を含む) 今回の企画には、14 名の応募があり、そこから抽選で 3 名の学生を採用としました。 応募の際に RubyKaigi に参加したいと思ったきっかけや動機を書いていただきました。 私は抽選をした後に読んだのですが、みなさんとてもモチベーションが高く、抽選前に読んでいたら全員に補助を出したいと思ってしまうぐらいの内容でした。
わたしが参加しているプロジェクトでは、今 Rails 5.0.0.rc1 で開発をしています。 先日コードを書いている時、気になる挙動があり、Issue をあげました。 Issue には再現させるためのコード片を記載していました。 この時、コメントで反応を頂いて知ったのですが、Rails には各コンポーネントごとにファイル単体で実行して確認するための再現コードのテンプレートが用意されているのですね。history を見ると 2013 年ごろからあるようですが、わたしは今回初めて気付きました。 中を読んでみると、bundler/inline が使われており、そのコードを Ruby で実行するだけで発生しているバージョンのライブラリがインストールされるようになっています。セットアップとテストを書けば、何をしているのか、何を期待しているのかがわかるようになっていました。 このテンプレートに沿って
@koic です。 GitHub などでイシュー管理しているプロジェクトは多いと思います。プロジェクトで開いているイシューの数はいくつありますか? 私はいくつかのプロジェクトで 100 以上のイシューが開いているのを確認しています。Rust では 8,000 以上のイシューが開いているので全然大したことないかもしれませんが、いつまでも放置していても見通しが悪いままなので整理するのは悪くないアクションです。 これは人それぞれの好みもありますが、オープンソースのような自由時間で行っている活動で、地球の裏側から開かれた (良かれとオープンされた) イシューをクローズするのは精神力を使うので、Stale bot のようなものでクローズするのは「問題 vs 私たち」の構図にするひとつの選択です。一方で業務の方ではもう少しきめ細かくクローズできると良さそうという考えを持っていて、本稿ではそんなお仕事で
TL;DR bundle-#{sub_command_name} というコマンドを作り PATH が通っている箇所に配置をすると bundle sub_command_name で呼ぶことができる。 本文 先日、X 回目の Rails Update 業を行いました。 今回の Rails Update 業は、久しぶりに再開したプロジェクトのため Rails 以外の gem から出されている deprecate warning を消すのに苦労しました。 その際、何のメソッドが呼ばれたことによって deprecate warning が出るのはわかっているので、bundler に入れている gem 群を grep できたらと思いました。 これを実現するには、以下のようなコマンドの組み合わせで実現できます。 $ bundle show --paths | xargs grep keyword これ
こんにちは、アジャイル事業部 9sako6 です。 私のいるプロジェクトで大きなエンハンスが行われ、その中で Polymorphic Association(ポリモーフィック関連) を使う場面がありました。 ポリモーフィック関連を選択した理由や行った作業、注意点について話します。 架空のサービスを例に説明を行います。 サービス概要 私たちが運営するサービスでは、Magician(魔法使い)と、その魔法使いが扱える Magic(魔法)を調べることができます。 この世界の Magic(魔法)に同一のものはなく、 ユニークです。Magic(魔法)はMagician(魔法使い)に属しています。 class Magic < ApplicationRecord belongs_to :magician end class Magician < ApplicationRecord has_many :m
aikyoです。 はじめに Ruby3.0で、型定義を書けるRBSが導入されました。 私は以前にRubyのFileクラスの型定義を書いたので、Cで書かれたRubyの組み込みライブラリの型定義を書くのもそこまで大変ではないよということについて書いていきます。 現在のRBSの状況 ただ、現在のRBSでは、まだRuby本体に組み込まれているクラスについても型定義が書かれていないものがあります。 なので、型検査をしたいと思ってもRBSに型定義がなければ自分で書くことになります。 Fileクラスの型定義を書いたとき 型定義を書こうと思ったはいいものの。何を参考に型を書くといいのかよくわかりませんでした。現在は TypeProfで型定義を生成してくれたりしますが、正しく推定できない場合があります。 そうなると、やはりソースコードを読んで型定義を書くしかないと思いました。 私はそれまでにRubyのソース
今月の頭に行われた SpeeeCoffeeMeetup01 へ参加するために、LT スピーカーとして登録し、発表してきました。 (いろいろあって、資料の公開がこの時期になってしまった…) 内容は、弊社の GitHub で公開している adhoq という RailsEngine を Rails5 に対応させた時のお話です。 Rails アプリケーションを Rails5 に対応させたお話はよく見かけると思い、RailsEngine を対応させてみたという話をしてみました。 スライド中で紹介している通り、adhoq は簡易的な集計レポートを作成するための SQL 発行を Rails アプリの画面でできるようにするための Gem です。 id:moro が作成したのを最近はわたしが細々とメンテしております。 RailsAdmin のようなアップデートまでできちゃう管理画面はいらないが、かといってデ
こんにちは、kasumi8pon です。 先日、仕事で調査をしているときに将来エラーが起こりそうなバグを見つけました。それに対して「今は対応しない」という選択をした話をします。 将来起こりそうなエラー 将来エラーが起こりそうなことがわかったのは、全文検索エンジンを利用している箇所でした。ある ID の集合を指定しその ID のデータを結果から除く処理をしていましたが、その除外対象の ID はサービスの成長と共に増えていくことが見込まれています。 いくつかの全文検索エンジンではクエリに含められる句の最大数を設定することができますが、除外対象の ID の数がその設定の値を超えたときにエラーが生じて検索ができなくなります。 対象のデータは今後も増えていくことが予想されますが現在は上限値より遥かに小さく、データの増加ペースから見積ると、少なくともこの先数ヶ月ではエラーは発生しそうにありませんでした
どうも、muryoimpl です。9/8 から 9/10 にかけて開催された RubyKaigi 2016 に総勢15名で参加してきました。 Bento Sponsor をやりました 事業部として3日に渡ってブースを出したり、 2日目の Bento Sponsor でお弁当を配ったりもしました。 ブースでは、3 日間で 800 個阿闍梨餅を用意し、皆さんのお越しをお待ちしておりました。用意した阿闍梨餅は、全てお召し上がりいただけました。ブースに立ち寄ってくださった方、質問してくださった方、陳列されていた私をいじってくれた方ありがとうございました! 事業部の名にある「アジャイル」と「あじゃり」をかけたダジャレとわかってもらえる予定が、存外わかってもらえずにダジャレの説明を求められるという3日間を過ごしました…… Bento Sponsor としては、お弁当の配布と、のし紙に弊社のロゴを模した
こんにちわ。はじめまして。@kajisha です。 推しの Vtuber は、因幡はねる組長 かわいいおそろしいあくまでびでび・でびる様です。 最近は、風見くくさんのものまねが好きすぎてよく観てます。 初 3D 配信はほんとにクオリティが高いのでぜひ観てみてください。 www.youtube.com このエントリでは、現プロジェクトでつかっている delegated_type について少し書いてみたいと思います。 delegated_type とは何か 以下の Pull Request で Active Record に導入されたものです。 github.com Active Record にはクラス継承のしくみとして STI が提供されていますが、 単一のテーブルにサブクラスに必要な属性ももたせることになるので それぞれのサブクラスに必要な(そしてそれらはほとんどが nullable な
次のページ
このページを最初にブックマークしてみませんか?
『esm アジャイル事業部 開発者ブログ』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く