プロダクトオーナーを経験してドメインを理解する感覚が身についたかもしれないという話 - pospomeのプログラミング日記
現在自分は会社の仕事で認証基盤とマイクロサービス向けのアプリケーションプラットフォームを構築していて、 役割としてはテックリードとプロダクトオーナーを兼任している。 自分が開発、運用するシステムは主に社内のエンジニア向けの仕組みなので、 問題解決対象が技術領域となっている。 "技術的な課題を技術で解決する" という性質上、 プロダクトオーナーもある程度技術を分かっていないといけないので現状兼任している感じである （正確に言うと People Management もしているので、Engineering Manager も兼任していることになるが、 今回の内容と関係ないので触れないでおく）。 チームに興味ある方は連絡ください。 1年前にチームを立ち上げて、今は8名体制になりましたが、まだまだエンジニアが足りません。興味ある方は連絡ください。DMMマイクロサービスアーキテクトチームでサーバサイ
テスト、正常系から書くか異常系から書くか - hitode909の日記
今週は同僚と毎日長時間ペアプロしていた。 おもしろかったのが、同僚のテストの書き進め方で、一番複雑な正常系のテストをちゃんと書いてから、その複雑なテストをもとに、いろんな条件を削っていって異常系のテストを作っていく、というところ。 僕は逆で、入力が空なら何も起きない、とか、一番簡単な異常系のテストを書いて、そこだけ通るのを確認して、よしよし、と進めていって、メソッド本来の動きは最後に確認して終わる。 変な進め方だな〜(主観)と思って眺めていたけど、たしかに正常系のテストが通っていれば、あとはバリデーションまわりのチェックとか、例外となる場合のチェックをすれば終わりで、異常系のテストがすごい速さで書かれていておもしろかった。 …という話をしたら、チームメンバーたちは正常系のテストから書きはじめるという人が多くて、正しくことを確認してから、1個ずつ前提となる条件を外してみて試す、と聞いて、同値
パーフェクトRails著者が解説するdeviseの現代的なユーザー認証のモデル構成について - joker1007’s diary
最近、パーフェクトRuby on Railsの増補改訂版をリリースさせていただいた身なので、久しぶりにRailsについて書いてみようと思う。 まあ、書籍の宣伝みたいなものです。 数日前に、noteというサービスでWebフロント側に投稿者のIPアドレスが露出するという漏洩事故が起きました。これがどれぐらい問題かは一旦置いておいて、何故こういうことになるのか、そしてRailsでよく使われるdeviseという認証機構作成ライブラリのより良い使い方について話をしていきます。 (noteがRailsを使っているか、ここで話をするdeviseを採用しているかは定かではないので、ここから先の話はその事故とは直接関係ありません。Railsだったとしても恐らく使ってないか変な使い方してると思うんですが、理由は後述) 何故こんなことが起きるのか そもそも、フロント側に何故IPアドレスを送ってんだ、という話です
チェリー本の増刷（第5刷）が決まりました＆これまでに書いたサポート記事のまとめ - give IT a try
お知らせ 先日、技術評論社の編集者さんから「プロを目指す人のためのRuby入門（通称チェリー本）の4回目の増刷（第5刷）が決まりました」と連絡がありました！ 増刷嬉しい〜😆これもひとえに今まで購入してくださったみなさんのおかげです。どうもありがとうございます！ プロを目指す人のためのRuby入門 言語仕様からテスト駆動開発・デバッグ技法まで Software Design plus 作者:伊藤 淳一発売日: 2017/11/25メディア: Kindle版 ちなみに増刷というのは、出版社が在庫を補充するために、まとまった部数を追加で印刷することを言います（書籍の内容は同じです）。 言い換えると、「増刷される＝在庫がなくなるぐらい順調に売れている」ということなので、著者や出版社にとってはとても嬉しい知らせになります。 まあ、普通の読者さんにとっては「ふーん」という話題ですよね😅 僕も自分で
ソフトウェア設計の言語化スキルを磨くこと｜qsona
たとえば設計について議論するときや、コードレビューで指摘をするときに、「なぜその設計が良いと思うのか？」について言語化するのが上手だと、確実に良いことがあります。 言語化が上手にできるかが一つの壁なのではないか、と感じることもあります。後輩を育てたりチームをリードするような立場になると、特に必要性を感じるのではないかなと。 自分も、うまく言語化できたことですんなり議論を進められていると感じることは多いですし、逆に直感的な良さを言語化できなかったことで直感に反する方向に進んでしまい、結果よくなかったというような苦い経験もあります。 前提: ソフトウェア設計の良さは静的には決まらない良い設計・良いコードとは何なのか。という質問に一言で答えるなら、「保守性が高い」ことだと思います。つまり、今後の変更・拡張を、高速にバグが少なく行えるような状態が良い設計・良いコードです。(一般的にはこれで70%く
iPadでプログラミングしてる人、今まで馬鹿にしててすみませんでしたァァァァ!!!! - Qiita
こちらの記事内容は3年以上前のものなので、記事内にあるアプリケーションなどの動作やUIは実際と異なる可能性があるのでご注意ください。 (2023/01/04追記) iPadでプログラミングwwwアホちゃうかwww ワイ「え？お前全部iPadでプログラミングしてんの？そんなん効率悪いに決まっとるやんw」 ワイ「せいぜいでっかい画面でGithubのコード眺めるくらいしかできないやろwてかハイライトすらないんじゃn」 ?!(Monokaiで表示されとるやんけ...) ワイ「おっ、おう。シンタックスハイライトくらいはできるんやな。」 ワイ「まあ、考えてみればそのくらいは余裕だわなwでもな〜wコードだけ書けてもプレビューは？流石にそれが出来ないことには使えるとはいえn」 ?!?!(localhostで立ててくれるんか...これならCDN使えば簡単なサイトくらいやったらiPadだけで楽に作れるやんけ.
女性も参加しやすい（でも女性限定ではない）Ruby勉強会を企画中です #tokyogirlsrb - give IT a try
お知らせ イベントページを公開しました！託児室もあります！たくさんのご参加をお待ちしております😃 techplay.jp はじめに タイトルの通りですが、現在、女性も参加しやすいRuby勉強会を有志のRubyistと企画しています。 まだ固まっていない部分もあるので変更される点が出てくるかもしれませんが、このエントリではこの勉強会の概要や開催のきっかけ等を書いてみようと思います。 【もくじ】 はじめに 女性も参加しやすい勉強会を開催しようと思った動機ときっかけ 女性の参加者や登壇者が目立ったRubyConf 男性でも女性でも興味がある勉強会には気軽に行けるようになってほしい 女性向けであることを明記しないと、女性の参加者は集まりにくい 勉強会の概要 登壇者と発表内容 ターゲットとなる参加者の方 運営チーム Q＆A Q. 女性限定ではなく男性も参加できるのはなぜですか？ Q. Rails
文系でもプログラマになれるのか - そーだいなるらくがき帳
ブログについたコメントに対する自分なりの考えを書く。 soudai.hatenablog.com 私は文系の大学生ですが、プログラミング興味を持ちプログラマになりたいと考えています。 とても難しい事は理解していますが、プログラマに就職するのは やはり難しいでしょうか？ もし可能性があるとしたら、就職先の探しかたや見分け方などの ことを教えてください？ お願いします。 文系でもプログラマを始めとするソフトウェアエンジニアになれるか？の答えは なれる。 例えば自分の周りでも id:daiksy さんとか @shinpei0213 さんは文系出身のソフトウェアエンジニアだしプログラミングしている。 もっと言えば自分自身、高卒エンジニアなので学歴がネックでプログラマになれないということは無い。 だがソフトウェアサイエンスをしっかりと学んだ人からするとスタートラインは後ろである、という事実はあるし、
バッチ処理の一部で 30 分以上かかっていた処理を 14 秒で終わるようにした話 - @watson1978 の日記
Ubiregi Advent Calendar 2018 の 18 日目です。 ユビレジではたくさんのお客様の大量の POS データをお預かりしており、様々なバッチ処理も実行されています。今回は特定のケースでバッチ処理の一部が 30 分以上かかっていた処理を 14 秒で終わるようにした話について書きたいと思います。前回の Ruby 2.5 の SEGV と闘った話 - @watson1978 の日記 に引き続き DTrace を使った話になります。 はじめに ユビレジでは CSV ファイルでお客様が特定のデータをダウンロードしたりアップロードできる機能があります。CSV ファイルにエクスポートしたり、CSV ファイルから DB に取り込む処理を Worker を起動してバッチ処理しています。 大量のデータを保有しているアカウントと同量のデータを用意して手元の環境で試したところ時間がかかるこ
Flutterで社員研修用のアプリを作った話 - pixiv inside
みなさんはじめまして。初めてじゃない方はお久しぶりです。ピクシブでAndroidアプリエンジニアをしておりますconsommeです。 ピクシブでは基本的に年一回、社員同士の交流を深めるという目的のもと、社員研修を開催しています。2018年は2泊3日の沖縄研修が計画されました。そのなかで研修運営チームから「社員研修で使うアプリを作れないか？」という相談を受けました。 研修中は基本的にチーム行動になるので、自分のチーム以外の人が何をしているかがわかりづらい。それなら各自で研修中に撮った写真を共有して、みんなで楽しめれば社員同士の交流につながるのではないか、そのためのアプリが欲しい、とのこと。 そう言われるとアプリエンジニアとしては作らないという選択肢はありません。ぜひやりましょう、ということで、社員研修を盛り上げるためのアプリを開発することになりました。 システム構成 アプリ側 アプリはFlu
なぜ我々はいまだに文字列でコメントを書いているのか - Qiita
あるいは、画像コメントのすすめ。 TL;DR 画像コメントのほうが意図が伝わりやすい 画像URLからツールチップで画像表示してくれるVSCode拡張機能があるよ その場で画像を作るSVGエディタもあったよ 問題提起 みなさんは、少し複雑なアルゴリズムを書くことになったときどうしていますか。 たいていの場合、いきなりコーティングに取り掛かるのでなく、 雰囲気をつかむためメモやホワイトボードに落書きすると思います。 特に幾何計算では簡単なものでも図を描いた方がいいです。こんな感じ。 図を書いたら後はコードに落とすだけです。 ね、簡単でしょう？ // 指定した直線を対称軸としたときの指定した点の鏡映位置を返す function flipVectorByLine(p: Vector, line: Line): Vector { // TODO: よくわかるコメントを書く const ln = ne
RubyKaigi2018 懇親会に酒は要らない！？"コードで懇親する"コード懇親会 - Speee DEVELOPER BLOG
架電芸人エンジニア*1の西（id: kohtaro24）です。最近スマホをiPhoneからBlackBerry KeyOneに変えました。物理キーボードの重量感を楽しんでいます。 現在はRubyKaigi2018に参加するためはるばる仙台まで来ており、RubyKaigi2018の二日目に開催されたコード懇親会についてレポートしたいと思います。 コード懇親会 "コード"懇親会ですのでイベント概要もGithubリポジトリ上で公開されています。 github.com 以下の引用にあるように、コード懇親会はお酒ではなくコードを媒介して懇親することをコンセプトに設計されています。 スポンサーをSpeeeが努めさせていただき、クリアコードの須藤(@ktou)さんにイベントコンセプトやデザインをリードしていただきました。 Rubyは楽しくプログラミングできることを大事にしているプログラミング言語です。み
毎週1時間のモブプログラミング枠を運用したところ、とても良いという話 - だいくしー(@daiksy)のはてなブログ
およそ一月前くらいに、同僚の id:hitode909 さんとモブプログラミングをやってみようということになった。 hitode909さんとはチームは別なのだけれど、最近週一で別チームに行ってペアプロなどをしつつ、知見の横展開や課題の発見などをやろうという試みをされていて、ではせっかくなので、と自分たちのチームに招いて軽くお試しでモブプロをやってみた。 blog.sushi.money モブプログラミングとは、ペアプログラミングをチーム全員にまで拡大したようなもので、1つのプログラムをプロダクトオーナーも交えたチーム全員で取り組む形式である。 セミナールームにエンジニア8人ほどで集まって、大画面ディスプレイにソースコードを共有しつつ、「コードを書く人（ドライバ）」と「それ以外の人（ナビゲータ）」とで1つの課題に取り組んでいく。 実装をチーム全員で取り組むため、知見が共有できたり、設計上の課
技術的負債のパターンと悪影響・原因・返却方法について考える - $shibayu36->blog;
先日飲み会で技術的負債についての雑談をしていた。結構いろいろな側面の話をしていたのだけど、技術的負債って一括りにしているのが今はあんまり良くなくて、負債の性質によって技術的奨学金、技術的FX、技術的年金などと言葉を変えると良いのではみたいな半分冗談で会話をしていた。 いろんな問題が技術的負債という一言にまとめられてしまっているので、負債の性質に合わせて、技術的奨学金、技術的FX、技術的年金、など用語を分けると良いのではないか、という話をした— 趣味はマリンスポーツです (@hitode909) 2018年3月27日 技術的負債について - hitode909の日記 それで技術的負債のパターンを見つけて、それによりどういう悪影響があるか、それがなぜ起こるのか、どう返却するかについて考えておくと良いのではと思ったので、今日思いついた3つのパターンをメモしておく。 思いついたパターンは3つ。 変
C++完全理解ガイド Rev1.4.01 - Qiita
はじめに C++を完全理解したので完全理解ガイドを書く。 最初に言っておくがタイトルは詐欺で、実際はポエムである。 僕は仕事でC++を書いたことはないのでなんか変なことを言っているかも知れない。 ところで無職になったので、普通にC++で職がほしい。 2018年6月から受託で仕事をもらい、毎日C++17を書いています。 2018年9月から雇用され、毎日C++17を書いています。 かなり雑に書いているはずなので、コメント等でどんどんマサカリを投げてほしい。 僕は何者か 工学部を卒業して4年ほど高校の理科教師をやっていたが、現在無職になった人。 工学部を卒業して4年ほど高校の理科教師をやっていた。 最初は良かったのですが、授業に慣れ、このまま自分の成長が止まってしまうのかとなぁと思い、辞めて無職に。 一ヶ月無職を楽しんだあと、某から受託でC++を書く仕事をもらい、C++17を書いている。 主にツ
プログラミング経験がない経営者のためのソフトウェア開発 11の事実 | Social Change!
今やどんなビジネスでもITが関係している。ITを支えているのはソフトウェアだ。あらゆるものがソフトウェアで実現される時代になった。そんな事業や生活に密接に関わるソフトウェアだが、その開発について知られていないことも多い。 とくに経営者がプログラミング経験がないことで、ソフトウェア開発のリーダーシップをとるときに的外れなマネジメントをしてしまうことがある。あまねく経営者がプログラミング経験があれば良いのかもしれないが、それは現実的ではない。 プログラミング経験がなくても、せめてソフトウェア開発の特性について知っておくと良さそうなこともあると思い、なるべく専門用語を使わずに本稿を書いた。 プログラミングは製造ではなく、設計である いまだにソフトウェア開発を、ビルや家屋の建築に喩える人がいるし、工場でモノを製造するようにプログラムが作られると思っている人もいる。 ここが間違いのもとだ。ハードウェ
提案：エンジニアに気軽に「バグ」というのはやめませんか？ - worker experienceの日記
もしかしたら私だけかもしれないです。ずれているかもしれません。 一般論ではないかもしれません。 でも、同じような気持ちになっているエンジニアがいるかもしれないので、 代表して言わせてください。 エンジニアに、気軽に「バグ」と言うのをやめませんか？ 最近立て続けに以下のようなことが起こっており、私と同僚が消耗しています。心がすり減ってます。ワーカーエクスペリエンスが低下しています。。。 ～～～～～～～～～～～～～～～～～～～ 「○○さん、この数値がバグなんだけど直してもらえる？」 →調べたらその週は祝日影響で、営業日が少ないだけだった。 「あのデータのバグはいつ直りますか？」 →データの集計定義の変更の依頼があり、変更前の状態をバグと呼ぶ 「この前入ってなかったバグなんだけど、次の開発に入れてもらっていい？」 →スコープ外のこと（担当がそれを忘れていた）をバグと呼ぶ ～～～～～～～～～～～～
プライベートでコードを毎日書き続けて２年以上が過ぎた
いつの間にか２年間継続してコードを書いていたので、その振り返りです。上のインコは日々僕を応援してくれる二羽のインコのうちの一羽です。この後本をボロボロに噛みちぎっていきました。 １年目との違い去年こんなポストを書きました。 このとき、自分はコードを１年継続して書いたわけですが、その後また１年継続してコードを書いていました。 １年目とは「書きたい」と思うものも変わりました。また、習慣を維持する労力も小さくなり、コードを書くことそのもの以外の、登壇などの時間を取れるようになりました。 この１年で新たにやったことツール作成markdownをMediumポストにするCLIツールAWS SSMで管理されたパラメーターを環境変数にInjectするツールGoogle Cloud Platform API向けに使える、goonと同様のDatastoreクライアント基盤作成AWS上にTerraform+An
エンジニアの次のステップへの勉強法 - Qiita
言われたものはだいたい作れるし、どんなプログラミング言語が来ても大抵書けそうかなってなったエンジニアがそこで成長が止まってしまう人を見かけることがあります。 技術が好きで、作ることが好きで、なのに環境に求められず成長が止まってしまっているんだろうと思います。 ここで成長が止まってしまう環境とは、 新しい技術の情報を仕入れて語り合うエンジニアが居ない 業務用件に高い技術が求められない 改善サイクルが遅い 開発プロセスなどをまとめる人がいない などです。 簡単に言うと、今はうまく仕事があるけれど、停滞している仕事場ですね。 下手にビジネス的に成り立ってしまっているので、それ以上成長をする必要がないのです。 まあ、そういう生き方もありかな？って思うので、それでいいやって思う人は続きは読まなくてもいいかなって思います。 ここから先はエンジニアとして技術を伸ばすことが楽しい、ものを作ることが楽しい、
SIerからフリーランスまで、広く経験を積み重ねた自分だからこそ、スタートアップでできること。 | TIMERS inc.
プロフィール Timers,Inc.Androidエンジニア。新機能開発を担当。東京都出身。大学卒業後、SIer, ITコンサルタント、フリーエンジニアとして幅広い開発に携わる。その後、2016年9月にTimersにジョイン。 フリーで感じた限界。スタートアップへジョインしたワケ-開発歴長いですよね。どういうきっかけですか？ 子供の頃は、サッカーや野球に夢中なスポーツ少年でした。 初めてコンピューターに触れたのは、大学に入った頃、Windows95が発売されて、興味をもったことがきっかけ。それで遊びはじめたのが一番最初ですね。徐々にのめり込んでいって、ブラウザゲームのプログラミングをやり始めました。 それをきっかけにコンピューターがすごく身近なものになり、プログラミングをはじめました。最初につくったのはフラッシュというブラウザゲームだったかな。友達と作り始めて、気軽に対戦できるゲームをいろ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
