Good Tech Lead, Bad Tech Lead｜Takayuki Sano
HRTech領域で「若者の価値を最大化する」事業を展開している株式会社Traimmuというスタートアップで共同創業者・CTOをしている佐野です。 突然ですが「Tech Lead（テックリード）」というポジションをご存知ですか？ Twitterの投票機能でアンケートをとってみたところ、約35%がテックリードになりたい、そして約半数がテックリードについてよく知らないとのことでした。 cf.) https://twitter.com/yppon_s/status/1086106209424306177 現在、弊社で「テックリード」ポジションのエンジニアを絶賛募集中なのですが、自分自身もテックリードとして働いた経験がなく、どういったエンジニアがテックリードとして相応しいのかを考えたり調べたりしている中で、Jason Liszkaさんの記事「Good Tech Lead, Bad Tech Lead
越境のススメ｜といとい
この記事は InHouseDesigners Advent Calendar 2018 13日目の記事です。 こんにちは。@toi_toi_yです。インハウスデザイナーです。 自分はサイボウズという会社で自社プロダクトであるkintoneのデザイナーをしています。 チームにはプロダクトマネージャー、エンジニア、QA、ライター、デザイナーなどなどいろんな役割の人がいます。 一般的に事業会社はしっかりと分業されていて、それぞれのロールに割り振られた仕事をしています。自分はデザインをして、エンジニアはコードを書いて実装するのが主な役割です。 自分はサイボウズに来る前に製作会社でWebサイトを作っていました。自分でディレクターもやるし、デザインもするし、コーディングもやるという分業とは程遠い環境にいました。 2年半前サイボウズに転職してきた当時、「ちゃんと分業されている！ 専門家がいるって素晴らし
スタートアップの技術選定とアプリケーションプラットフォーム - laiso
photo by pexels.com *1 この記事を書いたきっかけ niconegoto.hatenadiary.jp 「PinQulをクローズします」にて事業のふりかえりをしている文章の中に「アプリビジネスは完全にダウントレンドにある」という一節があって、ここから話題が広がっていったのを機に上記の記事を読みました。そして色々思うところがあったのです。 アプリビジネスは完全にダウントレンドというのは自分も前から思っていた。リッチな体験、通知を遅れることはアプリの利点だが、他PFからの流入なども含めたプロダクトのコアな検証はwebモバイルが1番早いはず。— sadakoa (@sadako_a_) August 16, 2018 (Twitter上で多くの共感を集めた投稿) 例えば「モバイルアプリがWebに負けはじめた理由」ではWebアプリがモバイルアプリに比べて優れているでろうという点
2017 振り返りと2018抱負
ちなみにけん玉はまったく上手くなっていない。とめけんができるレベル止まり。姪っ子がけん玉が上手で、会う度に対決しようと言われていたわけだが、僕の腕を見て鼻で笑われ、勝負しようと誘われることがなくなった程度である。悲しい。 そんなわけで2017年を振り返りつつ2018年の抱負を書いておこと思います。 CTO としてエンジニアブログを開発した会社で開発部ブログというのを数年ほど運営していたのだけど、書きにくいシステム（jekyll を使って git 管理＆デプロイ）ということで長らく不評であった。jekyll が悪いのではなくメンテナンスをしていなかったのが原因で、ローカルでの動作確認がまともにできなかったりしていた。jekyll は大好きだ。 そこで、ブログをゼロベースで作るかという話になった。その話は別の記事で書いたので興味ある人は読んでみてください。
技術要素編: web アプリが新陳代謝を続けるための依存関係の厳選（新規開発のメモ書きシリーズ1）
新規開発したプロダクトについて ｢世の中に URL は出ているが、まだ正式公開していない｣という微妙な位置付けなのでプロダクト名と詳細は避けつつ述べます。短めの開発期間で急いでつくって、慌てて年末にβ版をリリースしたところです。 次の動きに向けてまったりしたり、Inside Frontend の開催に向けて四苦八苦しているところでメモ書きです。 このシリーズの他の記事はこちら。 ビルド設定編: UA に応じた最適な JS バンドルの配信と webpack との距離感 コード設計編: context による縦軸分類とレイヤードアーキテクチャ アーキテクチャ編: SSR と CDN ( Fastly ) とユーザー依存情報の分離 依存するパッケージの厳選 新しい技術、ライブラリを試すこと、それらを使って生産性の向上にチャレンジすることは必要です。とはいえ、程度が過ぎると逆に生産性を下げかねない
フロントエンドの負債と向き合う - mizchi's blog
某所で書いたものを公開用に書き直したもの 前提 フロントエンドでTDDは難しい、というかほぼ不可能である。なぜなら事前に副作用をデータとして表現できるか不明だからだ。たとえばあなたのプロダクトの画面の何処かにボタンを追加するために、その内部表現を事前に思い浮かべることが可能だろうか？ react-redux などのFluxフレームワークは如何に副作用をアクションとして表現することで、テスト・デバッグのための情報を残すか、という視点で発展してきた側面がある。あの冗長なアクション定義は、全てデバッグのために書いていると言っても、過言ではない。それすら「Textは文字がある」といったトートロジーなデータになりがち。 フロントエンドの現実的な単体テストは、他の開発者のために、自分が書いたコードの要求を満たしているか検知する手段として、防衛的にテストアフターしておく。これぐらいしか現実的な手法がない
リモートワークへの努力とは何なのか - axross.io
リモートワークへの努力とは何なのか 僕が去年の11月にKaizen Platformに転職したこともあり、知り合いから「自分たちの会社でリモートワークを始めた/始めたい」関係の話を聞くことが多くなってきた。転職してまだ半年くらいだけど、僕たちの会社の取り組みや、それに対して僕が考えていることを書いてみる。 ここに書いてあることはKaizen Platformの他のメンバーと見解が違う場合がある。かつて弊社の技術顧問だった@naoya_ito氏はこれらの文化の土台を築いたが、彼はそれをルールとして縛ることはせず、ガイドラインとして残した。だから多様な見解があり、僕たちはそれを良しとして仕事をしている。 Kaizen Platform という会社にいる。この会社は文化的にリモートワークが根付いていて、働く場所と時間の制約がない。 時間や場所の制約がないので、同じ時間に同じ場所にみんなが集まるこ
クソコードと呼ばない - ppworks.jp
新しい現場にはいったときに心がけていること、クソコードと呼ばないこと。 誰かのコードを読んでいるとそりゃまあクソコードを見つけることがある。その時どう立ち向かうかという精神論の話。 例えソレがそうであってもソレを口にするとネガティブが蔓延する。思ってもイイ、でも言ってしまってはならない。あるフェーズに置いては必要だった し、現に動いていて価値を提供している のだ。あるべき姿を叫ぶの簡単だ。あるべき姿を見ているなら行動しないといけない。見つけたらリファクタだ。出来るところからやるんだ。 Shut the fuck up and write some code & 許可を求めるな Pull Request せよ— 🌈KOSHIKAWA (@ppworks) 2014年5月23日 クソはクソと言える空気や文化は大事。良くないものを指摘できるようにはしたい。口の前に手を動かそう。プログラマーなら
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
