日頃の作業を自動化して得られたもの - Pepabo Tech Portal
minne事業部のnissyiです。私は最近、運用・開発業務の時間を確保するために、便利なツールを導入したり、ちょっとしたプログラムを書いて自動化したりしています。今回は、日頃の業務の自動化を進めたことで得られたものについて書きます。 自動化を進めたことで得られたもの 身近なところで自動化は可能 自動化の損益分岐点 メンテナンスと分かりやすさ 最後に 自動化を進めたことで得られたもの 早速本題ですが、自動化に取り組むことで以下のようなメリットや学びを得ました。 時間を生み出し、他の仕事に取り組む時間を確保できる 自動化の手段を知ることで、他の場面で応用できる 作業に対して「これは自動化できないか？」と考えるようになる 自動化を進めると、生み出した時間で新たな自動化に取り組めて、さらにそれで時間を生み出して…と複利のように効率化を進められます。 身近なところで自動化は可能 エンジニアの業務に
個人的Rails開発環境構築2024
新規でRailsプロジェクトを始める時の個人的な環境構築についてまとめる。前提とする条件等は下記。 規模: ~中規模 開発者数: 個人 利用シーン: PoC作成・スタートアップ立ち上げ・並の業務アプリ開発等 基本戦略 利用シーン的に「思い立ったらすぐアプリの開発ができる」という感じの運用がしたい。極力セットアップで悩みたくないから必要なミドルウェアなどは全部Dockerでインストールできるようにして立ち上げれば終わり、の環境を作る。その環境の中で色々とコマンドを叩いたり、rails newやrails gなどでRailsアプリを作成していく。 この辺のRailsの初期セットアップの手間を出来るだけ省きたいのでtemplateとなるリポジトリを作成し、そこからcloneしてくるだけでOKにする。 フロントエンドはReactなどを使わずをRails標準のerbとHotwireを軸に開発する。開
個人開発で売上を立てるための“ニッチ戦略” 「エンジニアである」強みを活かして、確度の高い成功を
個人開発者・なる氏は、非エンジニアの経営者に聞いた、エンジニアであることのメリットと、エンジニア事業者の落とし穴、個人開発で売上を立てるための戦略について話しました。 なる氏の自己紹介 なる氏（以下、なる）：先に言わせていただきます。僕のLTはちょっと情報量が多くなっているので、QRコードとかをけっこう出しています。なのでQRコードが出てきたタイミングで、気になったら適宜読み取ってもらえるとうれしいです。 （参加者の）みなさんはたぶんエンジニアが大半かなと思っているので、お待ちかねの、エンジニアがずっと褒められる、そんな時間の開始になります。というわけで、「エンジニアがどれだけ有利か」。「なる」と申します。 （スライドを示して）目次はこのようなかたちです。 自己紹介をすると……。「X」（の情報）を置いています。フリーランスになって4年目で、特化領域として、テックのスタートアップさんをクライ
質とスピードとゆとり - KAKEHASHI Tech Blog
こんにちは。カケハシでソフトウェアエンジニアをしている椎葉（@bufferings）です。私の所属するチームでは先日「質とスピード」についてのふりかえりを実施しました。この記事では、チームが「質とスピード」をふりかえってどのようなことを話し合い、何を決めたのかご紹介します。 この記事は カケハシ Part 1 Advent Calendar 2023 10日目の記事です。今年のカケハシのアドベントカレンダーにはPart 1とPart 2があるので、両方とも楽しんでいただけると嬉しいです。 カケハシ Part 1 Advent Calendar 2023 カケハシ Part 2 Advent Calendar 2023 「質とスピード」の社内講演会 カケハシでは、9月に和田卓人さん（@t_wada）をお招きして「質とスピード」の社内講演会を開催しました。 講演中には社内のSlackで「わかる
【日本人エンジニア必携】英語命名規則の決定版 - Qiita
弊社Nucoでは、他にも様々なお役立ち記事を公開しています。よかったら、Organizationのページも覗いてみてください。 また、Nucoでは一緒に働く仲間も募集しています！興味をお持ちいただける方は、こちらまで。 はじめに 英語での適切な命名は、コードの可読性や保守性を向上させるために重要です。適切な命名規則を守ることがコードの理解や共有において不可欠です。 英語での命名規則を学び、適切な命名を行うことで、コードの読みやすさや保守性を向上させ、チーム全体でのコードの理解を促進する手助けとなります。 この記事では、日本人エンジニアが英語での命名規則を理解し、適切な命名を行うための指針を提供します。 命名フローチャート 変数 関数 クラス 1. 変数 1-1. boolean 1-1-1. 存在するかどうかのフラグ 名詞 + exists
バックエンドの5年分の技術的負債を返済し始めた話
ストレッチ専門店 Dr.stretch を運営する 株式会社nobitel でシステム開発に取り組んでいる Nsi です。 nobitel では「健康 × スポーツ × IT」を掲げ、全国約200店舗（2023年9月現在）の Dr.stretch で使われるお客様・店舗向け業務アプリ「Ficks」を社内で開発しています。 元々2018年に開発がスタートし、紆余曲折あり2021年にリリースしてから継続的な追加開発を行っていましたが、ようやく技術的負債の返済に向けて動き出せる体制になってきたこともありフロントエンド・バックエンド共に時間をかけてリファクタリングに取り組んでいます。 フロントエンドの取り組みについては業務委託の shinnoki さんに記事を書いて頂いていますが、 今回はバックエンドの取り組みについて紹介したいと思います。 背景 弊社でエンジニアチームが立ち上がったばかりの頃に制
設計/コードレビューで"常に"心がけるポイント - little hands' lab
株式会社ログラスの松岡(@little_hand_s)です。 little-hands.hatenablog.com ↑の記事でドメインオブジェクトの設計方針を書きましたが、それ以外の全般的な設計/レビュー観点について書きます。 非常に汎用性のある内容なので、数多くのプログラミング原則を覚えるより、まずこの観点でチェックできるようにすると即効性が期待できます。 前提として、階層化されたアーキテクチャ(オニオンアーキテクチャなど)を採用しているものとします。 ①レイヤーの責務違反の実装をしていないか ②高凝集/低結合になっているか 高凝集 クラスに関して メソッドに関して 低結合 ③ユニットテストを書きやすいか 合言葉 筆者執筆書籍 現場での導入で困ったら ①レイヤーの責務違反の実装をしていないか 例として、「ユースケース層にドメイン層のルール/制約に関わる実装をしている」場合はNGです。
できるだけ嘘を書かずに計算量やオーダーの説明をしようとした記事 - えびちゃんの日記
計算量についてのお話です。対象は、プログラミング経験はあるが計算量のことを知らない初心者から、計算量のことを知っているつもりになっている中級者くらいです。 数式を見たくない人にとっては読むのが大変かもですが、深呼吸しつつ落ちついて読んでくれるとうれしいです。 それから、この記事が自分には合わないな〜と思ったときは、（別の記事を Qiita とかで検索するよりも）この記事の一番下の 参考文献 にある本を読むことをおすすめします。Amazon の試し読みで無料で読めます*1。 TL; DR 関数の増加度合いのことをオーダーと呼ぶよ 計算量は、入力サイズ（など）を受け取ってアルゴリズムの計算回数（など）を返す関数だよ その関数のオーダーについての議論がよく行われるよ オーダーを上から抑えるときは \(O\)、下から抑えるときは \(\Omega\) を使うよ オーダーを上下両方から抑えたいときは
二分探索アルゴリズムを一般化 〜 めぐる式二分探索法のススメ 〜 - Qiita
0. はじめに 二分探索法は単純ながらも効果が大きく印象に残りやすいもので、アルゴリズム学習のスタート地点に彩られた花という感じです。二分探索というと「ソート済み配列の中から目的のものを高速に探索する」アルゴリズムを思い浮かべる方が多いと思います。巨大なサイズのデータを扱う場面の多い現代ではそれだけでも十分実用的ですが、二分探索法はもっとずっと広い適用範囲を持っています。 本記事では、二分探索法のエッセンスを抽象化して、適用範囲の広い「二分探索法の一般形」を紹介します。同時に無数にある二分探索の実装方法の中でも「めぐる式二分探索」がバグりにくいと感じているので、紹介したいと思います。 注意 1: 二分探索の計算時間について 二分探索の計算時間について簡単に触れておきたいと思います。例えば「$n$ 個の要素からなるソート済み配列から目的の値を探索する」というよく知られた設定であれば、 単純な
ペアプログラミングして気がついた新人プログラマの成長を阻害する悪習
最近、あまりプログラミングが得意でない人のサポートをする形で、長い時間にわたってペアプログラミングを行っている。そのなかで、気がついた悪い習慣と成長するための良い習慣というものをまとめてみる。 この記事のバックグラウンドとなる体系的知識が本になりました。 エンジニアリング組織論への招待 ～不確実性に向き合う思考と組織のリファクタリング あわせて読みたい 経営者マインドが足りない！vs. 現場に任せてくれない！の対立をなくすカードゲームをつくった話 新人プログラマに知ってもらいたいメソッドを読みやすく維持するいくつかの原則 新人プログラマに知っておいてもらいたい人類がオブジェクト指向を手に入れるまでの軌跡 ペアプログラミングして気がついた新人プログラマの成長を阻害する悪習 あきらめるにはまだ早い！ソースコードの品質向上に効果的なアプローチ 心理的安全性ガイドライン（あるいは権威勾配に関する一
「「技術的負債」を問いなおす」というタイトルでJAWS DAYS 2014で話してきた #jawsdays - Kentaro Kuribayashi's blog
JAWS DAYS 2014のImmutable Infrastructure(以下、II)に関するトラックに呼ばれたので、話をしてきました。Immutable Infrastructure時代のConfiguration Management Toolの要件およびその実装についてや最近のImmutable Infrastructureに関する議論(Orchestration編)というエントリを書いていたからということでしょう。 ただ、最近は首都大学東京ビジネススクール不合格記に書いたように、経営学関連の学習をずっと行っていて、すっかりそのような話題から離れてしまっていた、ありていにいえば特に興味を持たなくなってしまっていたので、進学していたら研究テーマのひとつにしていたであろう件について、だいぶ生煮えではあるけれども最近またそうした話題でネットが盛り上がっていたりもしたので、以下スライド
Qiita「成果が出るチーム思考」の秘密――「飲みでも敬語は崩さない」「議論ありきのリーン開発」 | サイボウズチームワーク総研
※ベストチーム・オブ・ザ・イヤーのサイトから移設しました プログラマが幸せに働ける環境を提供したい――。そんな思いで生み出され、いまや約50万の月間UUを誇る「Qiita（キータ）」。プログラミングの知識を記録・共有するサービスで、多くのプログラマから愛されています。 開発したのはIncrements株式会社。学生時代に関西で出会った3人が数年後に再会を果たし、それぞれが培った多様性のあるスキルを持ち寄り、会社を立ち上げました。「堅実に、着実に」――。サービス開発で大切にしていることを聞くと、こんな答えが返ってきました。徹底した仮説検証の積み重ねをベースに堅実な開発を進め、勢いだけで動かない。スタートアップらしからぬ体制が見えてきます。 この成功サイクルの秘密を「同じ価値観を持つメンバー同士で議論できること」と話すのは、同社CEOでプログラマの海野弘成さん。小西智也さん、横井孝典さんを交え
新人エンジニアに読んで欲しい英語ドキュメントまとめ (Ruby/Rails編) - Wantedly Engineer Blog
こんにちは！エンジニアの川崎です。 嬉しいことに、Wantedly開発チームの仲間は2013年の1年間で2倍に増えました。2013の最初には自分、 awakia と reikubonaga の3人でしたが、 デザイナなのにXCodeも使いこなす ferasyahin、 Chef使いのプロダクティビティ・エンジニア spesnova、それからこのブログのデザインもやってくれたエンジニア imaimiami の加入で合計6人になりました。最近ではさらに kento や shin-en がインターンとして活躍してくれています。 Wantedlyに入社してくるエンジニアは、なぜかRubyもRailsもやったことのない人ばかりなので(自分もそうでした)、 今日はそんな彼ら新人のために、Ruby/Railsで開発をするときに役立つページをまとめてみました。 初めてRails開発をする人に参考にして欲し
テストエンジニアリング、DevOps のこれから #testingcasual - naoyaのはてなダイアリー
一昨日 Testing Casual Talks #1 に参加した。名前の通り、ソフトウェアテストに関するカジュアルなカンファレンス。とても面白かった。すこし思ったところを書いていこう。 テストのエンジニアリング トップバッターの @ikasam_a さんの発表では Software Engineer in Test at DeNA ということで、氏が勤務先でテストエンジニアリング部門を立ち上げていくにあたってのいきさつや背景といったところが述べられていた。 テストは開発者の生産性を向上するためにある、生産性向上のためにテストを書くテストエンジニア、近年複雑化するテストの実行環境を構築するのもテストエンジニアの役目、"Testing Activities SHOULD be in Developments" ─ テスト活動は (従来型のQAのように開発の外ではなく) 開発の中で行われるべき
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
クックパッドの開発プロセス