開発現場の貢献実感のためにできること - ANDPAD Tech Blog
はじめに この記事はANDPAD Advent Calendar 2023 25日目の記事です。 こんにちは、アンドパッド代表の稲田です。 今回は、アンドパッドが取り組む、2024年の業界課題と、PdM / エンジニア / デザイナー / QA / CRE など開発チームに感じてほしい、アンドパッドの提供価値と、貢献実感についてのお話です。 少しでも、社会課題解決に貢献できるワクワクをお伝えできたらな、と思います。 アンドパッドが取り組む建築・建設業界 建築・建設業界は、 50 兆円を超える巨大な市場でありながら、生産性が低い産業の一つと言われています*1。 また、労働者の高齢化や、新規入職者の減少による人手不足が顕著で、 DX や SaaS での生産性の向上が急務と言われています。 日本の骨太な課題に深く長く取り組むのが、アンドパッドです。 建築・建設業界の2024年問題が迫る そんな中
設計書を書かない設計で開発効率を向上させた話 - Tabelog Tech Blog
この記事は 食べログアドベントカレンダー2023 の23日目の記事です🎅🎄 こんにちは。食べログシステム本部 技術部 仕入チームの@shohei-yです。 今回は、新規事業の「食べログ仕入」プロダクト開発において所謂「設計書」を書かない設計に挑戦して開発効率を向上させた話を書きます。 （結局「書くの？書かないの？どっちなんだい！」と感じた人は、ぜひ読み進めてください。） 所属している仕入チームについてはこちらの記事をご覧ください。 目次 なぜ設計書を書かない設計に挑戦したのか 設計書を書かないチーム 設計書を書かないことによる問題 1. チーム協力の課題 2. ソースコードの複雑化 3. チーム変動に関わる問題 設計工程導入のきっかけ 設計書を書かない挑戦の背景 設計書を書かない設計 フロントエンド・バックエンドのインターフェースの明確化 ソースコードのスリム化対策 設計のレビュー方法
Announcing Flutter 2
Share Facebook Twitter LinkedIn Mail Our next generation of Flutter, built for web, mobile, and desktop Today, we’re announcing Flutter 2: a major upgrade to Flutter that enables developers to create beautiful, fast, and portable apps for any platform. With Flutter 2, you can use the same codebase to ship native apps to five operating systems: iOS, Android, Windows, macOS, and Linux; as well as we
merge commitのrevert commitをrevertしてたけど気持ち悪いからやめました。 - クイック エンジニアリングブログ
こんにちは。mikkiです。 今回はGit運用でずっと気持ち悪いと思っていた、revertのrevertをやめる方法を見つけたので、こちらに記載したいと思います。 （もしかしたらこんなことしてたの私だけかもしれない。。。） Gitの説明は省くので、勉強されたい方は詳しく説明の載っている外部サイトをご覧ください。 サルでもわかるGit入門 〜バージョン管理を使いこなそう〜【プロジェクト管理ツールBacklog】 どんな時にrevertのrevertをしていたのか revertのrevertをせずに修正を加える方法 最後に どんな時にrevertのrevertをしていたのか developブランチから複数のfeatureを切り、developにmergeし動作確認を行っているとします。 追い越しリリースやバグが見つかった場合、対象featureブランチのmergeコミットをなかったことにしたい
VP of Engineering やめた - @kyanny's blog
2018年4月から務めた Quipper Limited の Vice President of Engineering を、2020年3月末日付で退任*1した。 なぜやめるのか 一言でいうと、 VPoE として担っていたミッションを完遂したため。 二年前に VPoE 就任を打診されたとき、自分が所属していた開発組織の課題は明白だった。人が辞める。定着しない。人が増えない（むしろ減る）ので現場の負荷が上がる。ムードも悪くなる。お世辞にもおすすめできる職場とはいえなかった。 そこで、「二年で開発組織を立て直す」をミッションに掲げ、上司と約束した。 結果、二年間でエンジニア組織は 25 名から 54 名へと倍増。かつ、ミスマッチを防ぐ採用方針を徹底したことで離職者を低く抑えることに成功。開発組織を安定化させた。 2017年3月 2018年3月 2019年3月 2020年3月 エンジニアの人数
OSSエンジニアを1年やってみた所感 - knqyf263's blog
最近脆弱性の話とか本業と一切関係ないことを書いていたので、今回は本業に関する話です。 前提 所感 楽しい やりがいがある 実績になる 得意な形でアウトプットできる 勉強になる 深く特定領域を学べる 得た知見を公の場で共有しにくい 広く触れない（可能性がある） なぜ会社としてOSSをやるのか？ということを真剣に考えられる 市場の熟成 有料化のしやすさ 品質の向上 カンファレンスでの発表 ファンを作る 会社の売上に貢献できる方が精神的に楽 ユーザからのフィードバックが助かる メンテナンスコストが高くなる 方針を決められなくなる 宣伝は必要 まとめ 2019/08/01にOpen Source Engineerという肩書になってから既に1年が経過しました。そういうポジションの人はまだ日本では少ないんじゃないのかなと思ったので何か参考になればと所感を書いておきます。ちなみに最初の頃Open Sou
「新機能作成時に開発ブランチに細かくmergeしていく戦略」について社内勉強会で発表しました - Hatena Developer Blog
はてなのアプリケーションエンジニアのid:shiba_yu36です。社内技術勉強会で「新機能作成時に開発ブランチに細かくmergeしていく戦略」という発表をしたので、資料を公開します。 speakerdeck.com 以下、簡単に文字でまとめておきます。 戦略 ユーザーに新機能が見えないようにする工夫をし、新機能のbranchもどんどん開発ブランチにmergeしていく mergeされたものは随時本番にリリースされるが、ユーザーに見えない工夫をしているので問題なし PRは可能な限り細かくする 機能が完成したら最後にユーザーに新機能を見えるようなPRを作り、mergeしてリリースする なぜこの戦略を使うのかいろんな失敗を経験して、この戦略を最近使っている。 失敗パターンその1: 巨大PRパターン 失敗パターンその2: 新機能リリースブランチパターン 失敗パターンその1: 巨大PRパターン 新機
覚えるだけでPythonのコードが少し綺麗になる頻出イディオム - タオルケット体操
まえがき 今年の春から今まで、2年ぶりにPythonを沢山書いているわけなんですが、JavaScriptのクソに頭をやられて久しぶり書くだけあって基本的なところから色々と頭から抜け落ちていたわけです。 そんで何か思い出すたびに会社のwikiを使ってメモっていたのですが、せっかくなので少々訂正をしてブログにも書きます。 また、弊社はPython2を使っているので、2が前提の記述になっているところがいくつかあります。なるべくフォローしていますが、参考にする場合は自分が使っているバージョンを確認することをおすすめします。 また、今から新しくPythonでプロジェクトを始めようと思っている人は3系を使いましょう。 知ってる人は当然知ってる、でも結構長いことPythonを書いてても知らなかったりするような小技を載っけました。 なお、メタプログラミングとかの黒魔術っぽい記事のまとめはこちら: hach
日本でアジャイル / DevOps 導入が進まないのは「文化」を変えないから - メソッド屋のブログ
私が初めてeXtreme Programming に出会ったのは確か2000年だと思う。実際に初めてのプロジェクトを実施したのが2001年。それからすでに15年が経過していることになる。そんな長い間アジャイル、そして DevOps の日本での導入に関わってきた。日本のアジャイル導入に関しては全て成功とは言わないが、かなり成果は上げてきたとは思う。だけと、今日は自分の導入ポリシーの誤りに気付いて、新たなステージにいける気がしたので、そのことを共有してみたい。 2002年 尊敬するアリスターコバーンと、XP JUG関西のメンバーと清水寺で。私が写真撮ってたのかなw Alistair.Cockburn.us | Alistair's first trip to Japan sept 2002 日本はアジャイルの導入がこれからという噂を聞いたけど本当？ これは、私がマイクロソフトの面接の時に、当時
yohgaki's blog - 画像ファイルにJavaScriptを隠す
(Last Updated On: 2014年12月5日)前回のエントリでイメージファイルにスクリプトを埋め込んで攻撃する方法について記載しましたが、最近イメージファイルにスクリプトを埋め込む事例が話題になったためか ha.ckersにJavaScriptをイメージファイルに隠す方法が紹介されています。 http://ha.ckers.org/blog/20070623/hiding-js-in-valid-images/ <script src="http://cracked.example.com/cracked.gif"> などとXSS攻撃を拡張する手段に利用可能です。サンプルとしてFlickerにJavaScriptを埋め込んだイメージファイルがアップされています。 このイメージファイルは上手く細工しているので画像としても表示され、JavaScriptも実行できます。 Flicke
Python のバージョン毎の違いとその吸収方法について - CUBE SUGAR CONTAINER
この記事の目指すところ 現在 Python はバージョン 2.x 系と 3.x 系という、一部に互換性のないふたつのメジャーバージョンが併用されている。 その上で、この記事にはふたつの目的がある。 ひとつ目は、2.x 系と 3.x 系の違いについてまとめること。 現状、それぞれのバージョン毎の違いはまとまっているところが少ない。 自分用に、このページだけ見ればひと通り分かる！っていうものがほしかった。 ふたつ目は、2.x 系と 3.x 系の違いを吸収するソースコードの書き方についてまとめること。 こちらも Web 上にナレッジがあまりまとまっていない。 これについては今 python-future というパッケージがアツい。 尚、サポートするバージョンは以下の通り。 2.x 系: 2.6 と 2.7 3.x 系: 3.3 と 3.4 本題に入る前に、最近の Python 事情についてまとめ
デザイナーとエンジニアが話す、iOSアプリケーション開発
デザイナー 大杉とエンジニア 中元寺が、Apple Store Ginzaで行われるイベントに登壇します。 内容 「デザイナーとエンジニアが話す、iOSアプリケーション開発」 iOSアプリケーション開発において、デザイナーとエンジニアがそれぞれどんな作業をし、どのように連携しているのか。「Sumally for iOS」の開発を例にiOSアプリケーション開発の一連の流れを解説します。iOSアプリケーションの開発に興味のあるデザイナー、エンジニアの方はぜひご参加ください。 日時 4月14日(火) 19:00 - 20:00 場所 Apple Store Ginza 予約 http://www.apple.com/jp/retail/ginza/ 上記ページから予約ができます。 満員になりましたので、予約を締め切りました。
Go言語の便利情報 - ゆううきブログ
ここ1年ぐらい収集した便利 Go 言語情報を並べただけです。 http://b.hatena.ne.jp/y_uuki/golang/ https://github.com/stars?language=go オフィシャル 言語機能解説を中心にピックアップ。 Effective Go - The Go Programming Language Go's Declaration Syntax - The Go Blog Share Memory By Communicating - The Go Blog Defer, Panic, and Recover - The Go Blog Go Concurrency Patterns: Timing out, moving on - The Go Blog Go Slices: usage and internals - The Go Blog
ブログにYoボタンを設置した
ブログにYoボタンを設置した 最近はほとんどのコミュニケーションがYoで完結している．得に日本はハイコンテキスト文化なので助かる．だいたい伝わってると思う．最近だとYoに人生を救われたひともいるくらいだ． さて，ブログを書いたあとにわざわざ「ブログ書いたので読んでください」などと言うのは，粋じゃない．さらっとYoするのが現代のスタイルだ． ということで，Yoボタンをブログに設置した． YoがインストールされたデバイスでこのYoボタンを押すと”SOTABLOG”というアカウントがYoのリストに登録される（PCとかだと手動で..）．すると，ブログ記事が更新される度に”SOTABLOG”からYoされるようになる． 仕組み といっても自分の個人アカウントが”SOTABLOG”で一人一人に手動でYoするわけではない．Yo Developers APIを利用している．やり方は以下． http://yo
リトライと冪等性のデザインパターン - Blog by Sadayuki Furuhashi
リトライを肴に一晩酒が飲める古橋です。 大規模なデータに触れることが日常茶飯事になっている今日この頃。この分野のおもしろいところは、いつまで経っても終わらないプログラムを簡単に作れてしまうことかもしれません。エラー処理、リトライそして冪等性*1の３つを抑えていないプログラムは、小規模なデータなら問題ないが、データ量が多くなると使い物にならなくなる可能性が大です。 大規模データをバッチ処理するケース以外でも、リトライは一般にプログラムの信頼性に関わる重要な問題です。 そんなわけで、リトライに関わるいくつかのデザインパターンを、連載でまとめておこうと思います*2。 では、第1回は背景から： なぜリトライが必要なのか プログラムは色々な理由で失敗する。例えば、 A) 通信先のプログラムが高負荷すぎて応答できなかった B) メモリを消費しすぎてメモリ確保に失敗した。またはOOM KIllerに殺さ
Qiita Hackathonに参加しました - blog.ishkawa.org
テーマはGitHub APIを利用してプログラマーの問題を解決するというものでした。 http://qiitahackathon03.peatix.com つくったもの Gitのコミット毎に親コミットとのdiffからTODO:やFIXME:というコメントを探し出し、 それを元に自動的にissueのオープン/クローズを行うツールをつくりました。 このツールを使うと、TODO:コメントの挿入/削除 = issueのオープン/クローズとなります。 あまりウケないかなと思っていたのですが、思いの外受け入れてくれた方がいて嬉しかったです。 スライド GitHubのゲストの方向けに資料は英語で書かれていますが、発表は日本語でした。 デモビデオ 発表のときはその場で実演しました。 かなり緊張しました。 (音声はありません。) 実装方法 いつも通り、Objective-Cで書きました。 前後のコミッ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
