タグ

ブックマーク / tech-blog.yayoi-kk.co.jp (13)

  • 🔦「お気持ち会」で暗闇を払う - 弥生開発者ブログ

    こんにちは、@mugi_uno です。気付いたら弥生社員になってました!! プロジェクトの立ち上げはむずかしい Misocaチームで何かしらの課題に取り組む場合、基的にはプロジェクト化して進めていきます。 その際、まずはインセプションデッキを作成して「目的やゴールは何か」「何をして、何をしないか」といったことを明文化し、メンバーで認識を揃える作業をします。 ですが、現実的にはそれ自体が難しいケースが存在します。 何から手を付ければいいのかわかりません! たとえば 多種多様な立場の人が参加するプロジェクトを始めるが、メンバー個々人が何を重要視しているかを互いに知らない ○○について効率化したいけど、具体的に何が課題で次に何をすべきかが誰もハッキリとは見えていない 膨大なタスクが存在していて、どういった判断軸で優先順位をつけていけばいいのかがわからない みたいな経験はないでしょうか。 このよ

    🔦「お気持ち会」で暗闇を払う - 弥生開発者ブログ
  • SlackワークフローとRubotyで最高のChatOps生活を - 弥生開発者ブログ

    Misoca開発チームの黒曜(@kokuyouwind)です。 富山Ruby会議が近づいてきましたが、10/23 午前11時現在、まだスライドを1枚も作ってません。4連休に着手するつもりだったんですが、シャニマスMTG Arenaに消えました。 あ、頭の中ではできあがってるから…… あとはスライドに書き出すだけだから……(震え声) 🤖 Slackワークフロービルダー 先日、Slackにワークフロービルダー機能が追加されましたね。 これはSlack上からメニュークリックや特定タイミングで起動するワークフローを作ることで、定型的な作業を自動化できるものになっています。 このような画面でワークフローを定義できます。 メッセージを送るだけでなく、フォームを表示したり、メッセージ内にワークフロー起動者の名前やフォームの入力を埋め込んだりなどができるようになっています。 ちなみに、弊社の@thar

    SlackワークフローとRubotyで最高のChatOps生活を - 弥生開発者ブログ
  • Misocaのリモートワーカーの仕事環境2019 - 弥生開発者ブログ

    こんにちは。@KawamataRyoです。 エンジニアになってから着々と体重が増えて、先日80kgの大台に乗りました。 大学の部活ではライト級(60kg以下)で試合に出てたのでその頃から20kgの増量。日々色々な方面で成長中です。 さて今回は、Misocaのリモートワーカーの仕事環境のお話です。 以前こちらの記事で紹介してから早2年、メンバーの入れ替わりもありリモートの環境も大分変わったと思うので、2019年度版を改めて紹介します。 @KawamataRyo リモート歴 基勤務時間 6ヵ月 8:00〜17:00 仕事環境のこだわり モニターアームがカッコいいと思い、無駄にディスプレイを浮かせています。キーボードの押打でめっちゃディスプレイが揺れるのが悩み 椎間板ヘルニア持ちなので、デスク、椅子は良いものを使っています。昇降デスクなので時々スタンディングデスクとしても使っています 隣にベン

    Misocaのリモートワーカーの仕事環境2019 - 弥生開発者ブログ
  • レガシーなフロントエンドコードを整理するためにどう立ち向かったか - Misoca開発者ブログ

    2エントリ連続でこんにちは、@mugi_unoです。 名古屋には台湾ラーメンイタリアンという名物があるそうです。 富山県民の私には理解が追いつきませんでした。 フロントエンドでの金額計算処理 さて、Misocaは請求書作成サービスなので、金額計算処理が欠かせません。 フロントエンドも例外ではなく、消費税額や合計額を算出するロジックが存在します。 機能変更が必要になった!! 諸事情により、そのロジックに変更を加える必要が生じました。 長くプロダクトを支えてくれていた存在ですが、内容的にはいわゆるレガシーなコードで、たびたび開発者ミーティングでも課題として挙げられることがありました。 git log で確認してみると、該当コードに対しての機能的な変更は2015年の冬から行われていません。 何が問題だったのか? DOM操作と計算ロジックの混在 Misocaでは、新しくコードを書く際はVueやRe

    レガシーなフロントエンドコードを整理するためにどう立ち向かったか - Misoca開発者ブログ
  • Turbolinks、時々Vue.js - Misoca開発者ブログ

    こんにちは、@mugi_unoです。 今年は雪がスゴいですね。 暖かい我が家でリモートワークのありたがみを日々噛み締めています。 先日は雪だるまを作りましたが、想像とは違う仕上がりになりました。 娘は「これじゃない!」と不満そうでした。 新しいRails&フロントエンドの環境構築 さて、最近Misocaでは、新規Railsアプリケーションのフロントエンド環境を整える機会がありました。 チームで検討した結果、Turbolinks&Vue.jsを採用しており、 その際に得られた知見を紹介したいと思います。 Turbolinksを使う理由 TurbolinksはGoogleで検索するとサジェストがこんな感じになるほど無効化されがちです。 利用するために理解すべき独自の挙動がある ゴリゴリにフロントエンドを触っている人からすると 「そこまでやらないで〜〜!」といった気持ちになる といった具合に避け

    Turbolinks、時々Vue.js - Misoca開発者ブログ
  • Rails 5.2 の足音 ~ Active Storage を試してみる ~ - 弥生開発者ブログ

    こんにちは、 id:eitoball です。 この記事は、Misoca Advent Calendar 2017 の15日目の記事です。 Rails 5.2 は、beta1 と beta2 が出てきて、正式なリリースも近々のようですね。皆さん、更新の準備はできていますでしょうか?今回は、Rails 5.2 の 目玉機能の一つである Active Storage を試してみようと思います。 Active Storage とは? Active Storage is coming to Rails 5.2: A brand-new framework for managing cloud and local files in Rails. Overdue! https://t.co/BFF4kWesT6— DHH (@dhh) July 6, 2017 Active Storage makes

    Rails 5.2 の足音 ~ Active Storage を試してみる ~ - 弥生開発者ブログ
  • よいコミットメッセージ・よくないコミットメッセージ - 弥生開発者ブログ

    こんにちは、mzpです。 今日はMisocaのesaに書いていた「よいコミットメッセージ・よくないコミットメッセージ」という記事を紹介したいと思います。 あらすじ 開発チームでは「コミットメッセージには変更理由を書いて欲しい」「コミットメッセージはWhatよりもWhyが大事」という話を何度かしているのですが、なかなか徹底できていません。 ので、もう少し具体的に「こういうコミットメッセージはよくないですね」というまとめを作ってみることにしました。 ちなみにこの過程でみつけたコミットメッセージに、こんなものがあります。 一切情報がなくておもしろいですね。 ファイル移動を移動した事実しか書かない これは以下のようなコミットメッセージです。 ファイル名を変更 ディレクトリを移動 ファイルを移動したことはコミットメッセージを見なくてもdiffから分かりますが、なぜその移動をしたかが分かりません。 の

    よいコミットメッセージ・よくないコミットメッセージ - 弥生開発者ブログ
    mikage014
    mikage014 2017/03/14
    コミットログで企業文化が分かる。採用面接に行く時はコミットログを見せてもらうと良さそうだ
  • 技術フェローが名古屋を流していたのでペアプロの手ほどきを受けたら捗った - 弥生開発者ブログ

    Misoca開発チームの黒曜(@kokuyouwind)です。 先日大須演芸場で開催された名古屋Ruby会議03ではTwitterでひたすら実況していました。大喜利が思った以上に大喜利で面白かったです。 お題「みなさんRubocopになってもらって『直しました』といってください。『何を直したんですか?』と聞くので、直したところを答えてください」 須藤さん「直しました」「何を直したんですか?」「RSpecをTestUnitにしました」 #nagoyark03— 黒曜@技術書典2 か-13 (@kokuyouwind) 2017年2月11日 流しの技術フェローに教わったペアプロのコツ 先日、弊社技術フェローのkakutaniさん(@kakutani)からペアプログラミング(以下ペアプロ)のコツを教わり、社内でのペアプロ機運が高まっています。 今回はkakutaniさんから教わった内容のまとめと

    技術フェローが名古屋を流していたのでペアプロの手ほどきを受けたら捗った - 弥生開発者ブログ
  • 及川卓也氏のプロダクトへの想いとプロダクトマネジメント - 弥生開発者ブログ

    こんにちは、Kosukeです。:) IncrementsのQiitaプロダクトマネージャー及川卓也さんがMisocaへいらっしゃったので、インタビューさせて頂きました! (左から共同創業者 松、及川さん、代表 豊吉、Kosuke) 及川卓也氏のプロフィール 一般社団法人情報支援レスキュー隊 代表理事。東京出身。早稲田大学理工学部卒。 専門だった探査工学に必要だったことからコンピューターサイエンスを学ぶ。 卒業後は外資系コンピューター企業にて、研究開発業務に従事。米国マイクロソフトに派遣され、Windowsの開発を行う。その後もWindows関連のプロジェクトに関わっていたが、どうせWindows仕事をするのならと、マイクロソフト株式会社(当時)に転職。 マイクロソフトではWindowsの開発を行い、最終的には日語版と韓国語版のWindowsの開発の統括を務める。 2006年にグーグル

    及川卓也氏のプロダクトへの想いとプロダクトマネジメント - 弥生開発者ブログ
  • 訳しました:「オブジェクト指向設計実践ガイド」 - 弥生開発者ブログ

    こんにちは。Misoca開発チームのtaiki-tです。 先日、を訳したのでそのことについて書きたいと思います。訳したは「オブジェクト指向設計実践ガイド ~Rubyでわかる 進化しつづける柔軟なアプリケーションの育て方」。 オブジェクト指向設計実践ガイド ~Rubyでわかる 進化しつづける柔軟なアプリケーションの育て方 作者: Sandi Metz,?山泰基出版社/メーカー: 技術評論社発売日: 2016/09/02メディア: 大型この商品を含むブログを見る 原著は”Practical Object-Oriented Design in Ruby” です。 Practical Object-Oriented Design in Ruby: An Agile Primer (Addison-Wesley Professional Ruby) 作者: Sandi Metz出版社/メーカー

    訳しました:「オブジェクト指向設計実践ガイド」 - 弥生開発者ブログ
  • ミニマムリリースを意識していたらコードが肥大化していた話 - 弥生開発者ブログ

    Misoca開発チームの黒曜です。 仙台へ温泉旅行に行ったついでに、アースキャンディが一時期話題になっていた仙台市天文台に足を伸ばしてみました。 常設展示やプラネタリウムも良かったのですが、なにより口径1.3mのひとみ反射望遠鏡が大迫力で素晴らしかったです。 夜は温泉宿へ行ったので観望会には参加できなかったのが残念でした。 Misocaならリモートワークができるので、いっそ仙台に長期滞在してみようか… 受発注機能とミニマムリリース さて、Misocaでは最近、受発注に関する機能を強化しています。 このブログを書いている時点で見積書をメールで送信すると、サイト上で見積に関するやりとりや発注を行えるようになっています。 しかし、受発注に関する一番最初のリリースは「通常の見積書受信画面に発注ボタンが出て、発注通知を送れる」というだけの大変シンプルなものでした。 受発注に関する機能はなるべくミニマ

    ミニマムリリースを意識していたらコードが肥大化していた話 - 弥生開発者ブログ
  • Sendgridでメールサーバのお守りから解放され、かんたんに受信メールを取り扱えるようになる話 - 弥生開発者ブログ

    こんにちは、@Dominion525 です。 好きな大長編は海底鬼岩城(旧)です。 メールサーバの管理は面倒 さて、Webサービスを行う際にわりと面倒なことが起こりがちなのがメールの配信です。 各種メッセージツールが充実している昨今とはいえ、基盤的なコモディティとしてのメールは無視することができません。 とはいえいろいろ運用は難しく、気を抜くとspam判定されて届かなかったり、大量に送った際には時間がかかりすぎたり、不達が多すぎてRBLなどのブラックリストに入れられて解除申請するはめになったり…、といろいろつらい思い出が蘇る感じがあります。 で、かなりの運用コストがかかるので、素の状態のMTA(Message Transfer Agent / メールサーバ)を自力で運用するのはそろそろやめたい気持ちでいっぱいです。だってもう2015年なんですよ? Sendgrid そこでMisoca では

    Sendgridでメールサーバのお守りから解放され、かんたんに受信メールを取り扱えるようになる話 - 弥生開発者ブログ
  • ソースコードを読むときの3つのステップ - 弥生開発者ブログ

    はじめに はじめまして。お盆明けからMisocaでインターンをしているhmryuです。Misocaにジョインする前は、個人でサービスを作ったり、研究でプログラムを書いたりしていました。 一方で、チームで開発する経験はあまりなく、Misocaにジョインした始めの頃は慣れないことばかりでした。中でも、他人の書いたソースコードを読んで理解することが、一番大変だったかもしれません。 そこで今回は、機能追加・変更を加えるためにソースコード*1を読む上で、僕が大切だと感じた3つのステップについて書きたいと思います。 1. 機能とソースコードの対応を調べる まず、自分が変更を加える機能がどんなもので、どこに実装されているのか理解する必要があります。実際にサービスを動かして、どんな機能なのかを確認します。その後、その機能がソースコードのどの部分に対応するのかを調べます。 例えば、メール送信について調べる場

    ソースコードを読むときの3つのステップ - 弥生開発者ブログ
  • 1