はてなブックマーク

最近の趣味はもっぱら 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

うおおおおおおおおおおおおおおおおおおおおおおおおおお。 子育て奮闘中の @wat-aro です。 この記事は ESM Advent Calendar 2022 - Adventar 19日目の記事です。 ある日 Slack のチャンネル一覧を眺めていると #うおおおおおおおおおおおおお というチャンネルがありました。 みんなで うおおおおおおおおおおおおお しています。 うおおおおしている様子 このチャンネル見つけてから毎日 うおおおおおおおおおおおおお しているわけですが、もっと うおおおおおおおおおおおおお したいわけです。 そんなわけで うおおおおおおおおおおおおお するプログラミング言語をつくりましょう。 繰り返し同じ言葉を使えるような言語であればたくさん うおおおおおおおおおおおおお できます。 そうですね。 Brainf**k*1 ですね。 Brainf**k での Hell

@koic です。 運用上の作業を開発者が行うというのは、昨今の DevOps ではよく見る光景だと思います。そして、運用手順の実施などにおいてダブルチェックというものを聞いたことあるでしょう。いや、むしろプロジェクトのルールで必要とされ、聞いたことがあるというレベルではないケースもあると思います。 そんなダブルチェック文化について、個人的には「ダブルチェックと聞いたらまず必要性を疑って判断する」という立ち位置で、本稿はそういった音楽性の人が書いた記事となります。 なお、一口に「ダブルチェック」といっても定義は広いため、「リアルタイムでの2人以上の指差し確認」を本稿でのダブルチェックの定義として位置付けます。 そもそも人間は間違えうるもの 本番環境へのショートサーキット 👿 Ops でも Dev のレビューフローにする 👼 形骸化したただの着席プロセスになっていないか疑う そもそも人間

こんにちは、hibariya です。さいきん GraphQL でのファイルアップロード方法について知りたいなと思いちょっと検索してみたところ、すぐにはこれといった方法に辿りつけなかったので気になって調べました。手元で試した感じだと GraphQL multipart request specification という仕様が良さそうでしたので、今日はそのことについて紹介したいと思います。 GraphQL でのファイルアップロードはめんどう 現在のところ、GraphQL の仕様ではファイルアップロード方法については特に規定されていないため、自分たちで方法を決めて実装する必要があります。が、これは少し面倒です。HTTP で GraphQL を使う場合、サーバに渡す値はたいてい JSON のようなフォーマットでシリアライズしますが、FileオブジェクトはそのままJSONにはエンコードできません。

HELLO WORLD〜 はじめに こんにちは、永和システムマネジメントの自作CPUおじさん、はたけやまたかし( @htkymtks )です。 今回はRubyを使った小さなRISC-Vシミュレータの作り方をご紹介します（以前もシミュレータの記事を書いたのですが、シミュレータに大幅に手を入れたので、それに対応したHDリマスター版です） リポジトリ （今回ご紹介するシミュレータのリポジトリはこちら） thata / rv32sim https://github.com/thata/rv32sim RISC-Vとは RISC-VはCPUの命令セットアーキテクチャ(ISA)のひとつで、使用料のかからないオープンソースライセンスで提供されていることや、命令セットの美しさから最近注目を集めています。 仕様 RISC-Vの仕様にはワード幅(32ビット、64ビット)や浮動小数点数サポートの有無など、いくつ

こんにちは。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 で立ち上げたコ

永和システムマネジメント東京支社オフィスは2022年10月を持って閉鎖します。 2015年5月に神田須田町に移転して以来、コワーキングスペースを設けたオフィスとして、 Asakusa.rb をはじめ多くのコミュニティに活用いただいておりましたが、リモートワークの推進もあり、この度閉鎖する運びとなりました。 今後については、固定オフィスを閉鎖した代わりに、レンタルオフィスである WeWork との契約を進めました。リモートワークに加えて WeWork を、働き方の選択肢のひとつに加えて業務を推進していきます。 WeWork の会議室を活用した対面でのコミュニティ活動についても、コロナ禍の様子を見ながら検討していきたいと考えております。引き続き多くの皆様とお会いできることを楽しみにしています。 最後に、来ていただいた多くの方々のサインを貼っておきます。皆様、ありがとうございました！ 株式会社永

こんにちは、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 でサーバ側を実装するときに起こりがちな問題として、クライアントから投げられるク

最近 ESM と RISC-V のロゴの配色が似ていると感じている @wat-aro です。 はたけやまさん の blog.agile.esm.co.jp はおもしろい記事でしたね。 この記事は最後こう締めくくられています。 以上、Rubyを使ったシンプルなRISC-Vシミュレータの作り方のご紹介しました。 皆さんも梅雨の時期のおうち時間にお好きなプログラム言語でCPUシミュレータ自作なんていかがですか？ なのでこの記事を参考に Rust で RISC-V シミュレータを作成しました。 https://github.com/wat-aro/rv32sim.rs 処理の流れはだいたい元記事と同じですのでもっと詳しく知りたい人は元記事からどうぞ。 メモリ まずメモリの定義です。 write と read と、初期データの読み込み用の initialize メソッドを持っています。 32 bit

読書の秋ですね。書棚を見ればその人がわかるといいますが、永和システムマネジメント アジャイル事業部でも運用している書籍購入支援制度で購入されている書籍をリストアップします。 この制度自体が運用し始めて長くなってきているため、直近の一年くらいに絞った内容です。メンバーたちがどのような書籍を購入しているか、読書の秋の参考にどうぞ。 Ruby JavaScript / TypeScript Rust Web データベース クラウド ソフトウェア設計 Linux 運用 その他 最も購入されていた書籍 (ESM Bookshelf of the Year 2022) 🥇 ★は複数人が購入。★★はその中でも購入が多かったタイトルです。 Ruby @kakutani フェローが絶賛翻訳中の『研鑽Rubyプログラミング β版』がよく購入されており、特に昨年の Kaigi on Rails での @kak

2004年中途入社の koic です。来月で入社17年。長いですね。 17年の間で人や技術が流転する長い勤務の中で伝承の途切れを観測していることから、私がいまの勤務先に入ったころ Wiki への考え方への影響を受けたものを発掘してみました。今回、私的解釈を交えて一般公開します。 はじめに 『ドキュメント記述の心構え』原文 私的解釈 {{toc}} 木構造よりも、ネットワーク構造を好め ネストしたリストよりも、見出しによる構造化を好め リストで文章を区切るよりも、空行をあけてPタグでレンダリングせよ 安易に項目追加する前に、リオーガナイズを検討せよ 正規化と重複の均衡点を探せ PREとQUOTEを使い分けよ リオーガナイズのメカニクスを用意せよ おわりに はじめに 本記事で取りあげるのは 2006年以前に「ドキュメント記述の心構え」 (WikiName は DeciplinesOfWriti

こんにちは、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

エンジニアリングマネージャーの @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/ そんなわけで今回の勉強会は本当に楽しみで、勉強会直前に会社のエントランスで牛尾さんと鉢合わせたときは一瞬頭が停止してしまったほどでした。 「今日の

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 開発でやりとりしている開発者とのオフ会

イベントで配布するノベルティとして、オリジナルのプランニングポーカーデッキを作成しました。 RubyKaigi 2018のスポンサーブースで配布したので、すでに持っている方もいるかもしれません。 11/1, 2 に開催されるRubyWorld Conference 2018のスポンサーブースでもお配りいたします。 参加される方はぜひお立ちよりください。 今回は私たちが作成したプランニングポーカーデッキについて紹介します。 プランニングポーカーとは プランニングポーカーはチームでユーザーストーリーなどを見積りを行うための方法です。 プランニングポーカーを使いチームで見積ることにより、チームメンバーでストーリーに対して議論することにより、 各メンバー間でどこまで何を行うストーリーなのか、やるべき事や落とし穴がないかなどの認識を合わせることを目的としています。 作成したプランニングポーカーデッキ

@koic です。 GitHub などでイシュー管理しているプロジェクトは多いと思います。プロジェクトで開いているイシューの数はいくつありますか？ 私はいくつかのプロジェクトで 100 以上のイシューが開いているのを確認しています。Rust では 8,000 以上のイシューが開いているので全然大したことないかもしれませんが、いつまでも放置していても見通しが悪いままなので整理するのは悪くないアクションです。 これは人それぞれの好みもありますが、オープンソースのような自由時間で行っている活動で、地球の裏側から開かれた (良かれとオープンされた) イシューをクローズするのは精神力を使うので、Stale bot のようなものでクローズするのは「問題 vs 私たち」の構図にするひとつの選択です。一方で業務の方ではもう少しきめ細かくクローズできると良さそうという考えを持っていて、本稿ではそんなお仕事で

こんにちは。永和システムマネジメントの内角低め担当、はたけやまです。 作成したプログラムが想定していた速度で動かず困ってしまうこと、ありますよね？ パフォーマンス改善を行う場合、プロファイラなどを使ってプログラムを計測し、どこがパフォーマンスのボトルネックとなっているかを見つけることが重要です。 Ruby プログラムをプロファイリングするための方法はいくつかありますが、今回は stackprof を使った方法をご紹介します。 stackprof https://github.com/tmm1/stackprof stackprof を使ったプロファイリングは以下の手順で行います。 計測対象のプログラムに stackprof を仕込む 計測対象のプログラムを実行する 計測結果からボトルネックを割り出す 計測対象となるプログラム 今回は例題として以下のライフゲームを計測してみます。 lifeg

こんにちは。永和システムマネジメントの内角低め担当、はたけやまたかし( @htkymtks )です。 Amazon Dash Button に触発されて「勤怠ボタン」をつくってみたのでご紹介します。（↓こんなのです） Amazon Dash Buttonに触発されて、Wi-Fiにつなげる小さなマイコンESPr Developerで勤怠ボタンを作ったよ。在宅作業開始時に🏠ボタンを、作業終了時に🔚を押します。 pic.twitter.com/4GUOM1RyBe— はたけやまたかし (@htkymtks) December 9, 2016 勤怠ボタンとは？ 私の所属する永和システムマネジメントでは在宅勤務が認められています。部署ごとに在宅勤務の運用ルールは異なりますが、私の所属するアジャイル事業部では在宅勤務時の作業開始と終了の連絡を社内チャットツール「Idobata」 *1 へ投稿するル

ESM Advent Calendar 2022 - Adventar 5日目の記事です。 こんにちは。 ima1zumi です。 アジャイル事業部で行っているエンジニアお茶会という場について紹介します。 エンジニアお茶会とは何か？ エンジニアお茶会とは、技術ニュースなどのトピックを持ち寄って技術ネタで雑談する会です。 Helpfeel さんの技術ブログで "「エンジニアお茶会」という取り組みについて" という記事があり、こちらを参考にはじめました。 blog.notainc.com 当時「他のプロジェクトのメンバーとも技術的な雑談をして交流したい！」と思っていたところにこのブログを読んで、まさにこれだ！と感銘を受けたことを覚えています。2022年2月から開始して今までに10回開催しました。 会の概要 月1回1時間、オンラインで開催しています。 会場は Slack の Huddle です。

もう来週は、RubyKaigi2018ですね。 今年は弊社から、18 名のメンバーが参加します。 RubyKaigi に各メンバーが様々な関わり方をするので、この記事ではそれをまとめていきたいと思います。 RubyKaigi 二日目に @koic こと伊藤 浩一が登壇します まずは、スピーカーとしての参加です。 @koic が二日目の 13:00 より会場 Hagi にて、Improve Ruby coding style rules and Lintを発表します。 プロジェクトでのコードレビューや Ruby / Rails の変更点などから得た知見を、コーディングスタイルや Linter として RuboCop に還元していくという話です。 RuboCop を使っている方は、どうやって RuboCop が改善されていっているのかを是非その目で確認してください。 RubyKaigi の当日

Rails / OSS パッチ会を2018年9月12日(水)に開催します。 この会をひとことでいうと、日頃のお仕事で使っている Rails をはじめとする OSS への upstream にパッチを送る会です。 会には Ruby と Rails のコミッターである顧問の a_matsuda もいますので、例えば Rails に送るパッチのネタがあるけれど、パッチを送るに適しているかの判断やパッチを送る流れが悩ましいときなど a_matsuda に相談して足がかりにするなどできます。 開催時間は 17:00-19:00 となりますがご都合のあう方はぜひご参加下さい。特に募集ページなど設けませんので、興味のある方は永和システムマネジメントの神田オフィスまでお越し下さい。 agile.esm.co.jp 終わった後は有志で懇親会などあるかもしれません。

こんにちは。 Ruby x Agile というグループに所属しながらRubyにまつわる記事を一つも書いていない気がするe.mattsanです。 今回もRuby以外のお話です。 RISC-Vシミュレータ作り、おさらい プログラミング言語Elixir RV32Simを実行する RV32Sim.Register 初期化 読み出し 書き込み RV32Sim.Memory 初期化 読み出し 書き込み Memory-mapped I/O RV32Sim.Instruction add beq RV32Sim.CPU RV32Sim プログラミング言語には意外な側面がある RISC-Vシミュレータ作り、おさらい 今、なにやらRISC-Vシミュレータ作りが流行っているようです。 局所的かもしれませんけれども、流行っていることにします。 Rubyでできる！RISC-Vシミュレータの作りかた 〜 From 4

こんばんは。 @hrysd です。 弊事業部には @takkanm が管理しているアカウントリストというスプレッドシートがあります。 これには、メンバーが各サービスで使用しているアカウント名等が集約されていて新しいメンバーが増えた時なんかに更新されています。 スプレッドシートどこにあるの問題 スプレッドシートの URL を覚えていないので、どこにあるのか全く見当がつかないという理由から、 日常的に使用している esa.io に貼り付てみました。 これだとスプレッドシートの内容で検索する事が出来ないため、Google Apps Script を使用してスプレッドシートの中身と記事の更新を連動させたいと思います。 Google Apps Script を書く スプレッドシートを開きツールバーの ツール > スクリプト エディタ を開く事で Web 上から編集を行う事も出来ますが、npm のモジ

終了して 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 で実行するだけで発生しているバージョンのライブラリがインストールされるようになっています。セットアップとテストを書けば、何をしているのか、何を期待しているのかがわかるようになっていました。 このテンプレートに沿って