優秀なプログラマになるために - @ledsun blog
みんな良いこと言うので、刺激を受けて考えたことを記録します。 生きてるだけで丸儲け ストレス対処法 撤退戦術 タスク殺すマシーン 人間に戻る儀式 運 技術力を身につける方法 車輪を再発明する 脱ゴールデンハンマー病 学習の助 優秀なプログラマとは？ おまけ 生きてるだけで丸儲け 優秀なプログラマーになるためのコツ · GitHub 優秀なプログラマーに「育つ」んだし、それには時間が必要 優秀なプログラマーになるということは、上記の通り長時間を要するということも踏まえると、メンタルヘルスにリスクがある環境に長時間暴露されることが不可避である 業界で長きにわたり活躍し続けている人というのは、それだけですでにひとかどの人物 すごく良いです。 優秀なプログラマになる前に、死んでしまっては元も子もありません。 生き延びることはなにより大切です。 幸か不幸か現状のIT業界はハードなストレスにさらされや
既存のサービスを組み合わせて本質的な開発に集中する - star__hoshi's diary
qiita.com 個人開発アドベントカレンダー9日目です! (2週間遅れです... 🙏) 一年前に開発してた Web サービスで、このような構成の開発をしていました。 個人開発はとにかく時間が足りないので、既存のサービスを使える場合はそのサービスを使って開発を行いました。 開発していたものは結局リリースしなかったのですが、CI や SaaS を使い快適に開発できたので、使っていたサービスや構成について書いていきます。 これは個人開発での遊びであり、これで商用サービスもいけるかというとわかりません。 (それと私は iOS エンジニアであり、サーバサイドは門外漢です) サービス概要 Lastfm のような、音楽を再生したらその履歴をとって何回再生したか、いつどこで再生したかなどを自分が聞いた音楽を歴史として遡れるようなアプリを作っていた。 メインの技術スタックは Rails + Herok
【翻訳版】Docker, Inc is Dead - comix
What's this? Docker, Inc is Dead の翻訳記事です。 ご本人の許可は取っていますが、僕が英語ペラペラではないため、読み辛いのはもちろん、一生懸命訳してはいますが誤訳・ミスリードなどあるかもしれません。 ですので、100%正確な内容を把握したい方は原文をお読みください。また、ここ間違ってるよ！ニュアンスが違うんじゃない？などありましたらお気軽に（優しく）コメントいただけると幸いです。 Docker, Inc is Dead / Docker社は死んだ Dockerにとって、2017年は非常に辛い1年だったと言っても過言ではありません。Uberを除いて、より活用され、賞賛され、十分に資金提供を受けたシリコンバレーのスタートアップの中で、Dockerが2017年に行ったような悪手を打ったスタートアップは思い浮かびません。人々は2017年を、ソフトウェアの偉大な一部分
2018年のサーバーレス - yoshidashingo
セクションナイン の 吉田真吾（@yoshidashingo）です。 さて、前回の記事では今年のカンファレンスの開催報告をしました。今年もサーバーレス盛り上がりましたね。 yoshidashingo.hatenablog.com トレンドをみると東京でカンファレンスを初開催した咋秋から、グローバルで4倍近いアテンションに高まっています。 さて、ここでは今年のサーバーレスの動きを振り返って頭の中をダンプしますんで、界隈の人と賛否両論なフィードバックをネタに年始の飲み会などができると嬉しいなと思っています。 1/24(水)に次回のServerless Meetup Tokyoを予定してますんでそちらはまた別途告知しますね。 エコシステムの発展 フレームワークツール サーバーレススタートアップ コンサルタンシー／エージェンシー プラットフォーム AWS Microsoft Google サーバー
「労働者側の裁量で深夜労働もできる勤務体系」をまじめに考えるとクッソ大変な話 - terurouメモ
これを読んだ。 tech.grooves.com 就業規則おじさん枠として、「労働者側の裁量で深夜労働もできる勤務体系」について言及しようと思う。労働法のエキスパートではないので、実際に検討をする場合は社労士と相談が必須。 お前誰よ 過去にこんなことをした。 terurou.hateblo.jp 本業ではないので労働法のエキスパートではないが、 自分で就業規則をゼロから書き起こした零細企業実務者 就業規則は執筆中～施行前まで社労士チェックが何度も行われている みなさんが期待する裁量労働制・なんでもありフレックスタイムを本気で検討したが、制度設計・運用がともに無理だと思ったので断念した という前置きで。 蛇足だが、就業規則をGitHubをした影響で本業の社労士さんからコメントを頂くことがチョイチョイあるが、「ちょっと気になるところがあるけど、大体こんなところだよね」という評価である。 元記事
そろそろコードレビューそのものの必要性について考えるときがきているのかもしれない - タオルケット体操
技術ブログの方に書くか迷ったのですが、かなりポエムの類な文章になりそうなのでこちらに書きます。 ちょっと前にバズったこちらの記事 medium.com に触発されました。 ちなみにコードレビューに関する話としてはまだ僕が色々と手探りだった3年前にもこんなことを書いていたようです。3年前の自分の考えに触れられるブログって面白いなという気持ちとこいつどんだけ軽率な文章書いてんだよという気持ちが合わさり甘酸っぱい気持ちが生み出されました。 hachibeechan.hateblo.jp 当時と今では日本全体の技術的トレンドも変わっていますし、そもそも僕の所属している会社も違います。今の会社ではGitHubを使っており、コードレビューが当然のフローとして組み込まれています。 そしていま改めて当時のブログを読み返したのですが、びっくりするほどコードレビューに対する僕の考えが変わっていないので、改めて
仕様や実装方針の相談をPullRequestで行う取り組み - $shibayu36->blog;
これまで少し大きめな機能であれば、コードを書く前にまず仕様や実装の方針をissueのdescriptionにまとめ、それを先にレビューしてもらってから実装にとりかかるということをしていた。最近、その方針をそもそもrepositoryのファイルとして書いて、PullRequestしてレビューしてもらうようにしたら便利だったのでご紹介。 なぜコードを書く前に仕様や実装の方針をレビューするのか 前提としてなぜコードを書く前に仕様や実装の方針をレビューして欲しいのかについて書いておく。これはとにかく手戻りの量を少なくしたいという要求のためである。 実装に取り掛かろうとすると、実装の方針はいくつか思いつくが、どれが一番よいか迷うことはよくある。その場合に誰にも相談せず自分だけで判断し、コードを書いてからPullRequestを送った場合、もしその選択に重大なミスがあった場合全て書きなおさないといけな
RedmineがIoT企業に異常にマッチしてしまった話 - 僕のYak Shavingは終わらない
タスク管理してますか？(あいさつ) みなさんは日頃どんなタスク・プロジェクト管理ツールを使っているでしょうか？ Backlog？Trello？Wunderlist？それともgithubのIssueで十分？カンバンほしいからZenhub？Waffle？変化球でProducteev? 僕も前職含めて上記含むすべてのツールを試してみました。 各タスク管理ツール所感 Trelloのガントない問題 ポンポンタスク登録できて便利。人のアサインも簡単だし。あ、でもこのタスクの粒度細かすぎない？依頼するときもされるときも細かすぎない？一つのリスト長すぎない？ あと標準でガントがないよね？全体見渡す側からすると不安（らしく）になっちゃうからやっぱりガントほしい。アサインできるの便利だけど、あぁでもこれボード6個くらいできちゃった。横断めんどい。どのボードもカードで溢れている。ガント追加してくれるサードパーテ
デモやプレゼンをするときに使っているツール - ikeike443のブログ
僕はいまソリューションエンジニアというロールで、お客さん先で GitHub や DevOps(バズワード)的なツールのデモをやったり、セミナーやカンファレンスでトークすることが多いのですが、デモやプレゼンをするのに自分が使っているツールをまとめておくと誰かがもっといいものを教えてくれるかもしれないと思い、ここに書いておくことにしました。 別のアカウントを作る まず最初にやってるのがこれで、Mac上に、普段使いとは別のデモ用アカウントというのを作っています。デモやプレゼン中にFacebookのメッセージが飛んできたり、Slack上のふざけた投稿とかが出てきて場を凍らせないようにするためですw 共有したいファイル（VMのイメージとか、プレゼン資料とか）は /Users/Shared/ 以下に置いています。ものによっては Dropbox を使って共有しているものもあるけど。Dropbox を使う
Shibu's Diary: ソフトウェアの世界は螺旋を周りながら進歩している
渋日記@shibu.jp 渋川よしきの日記です。ソフトウェア開発とか、ライフハックを中心に記事を書いていきます。 npm周りでごたごたがありました。その前にはCocoaPodの問題もありました。その前にはGemの話も話題になりましたよね。 うんこれ。2年ぐらい前にnode.jsで開発していた時にも、node.jsのnpmのエコシステムいつか破綻するよなぁって思ってた。で、去年cURL as DSL作ったんだよね。Rubyのコード生成はまだないけどね。 https://t.co/1C0yw0KPib — 渋川よしき (@shibu_jp) March 6, 2016 上記のツイートはgemに絡んでのツイートであって、コンテキストはnpmではなかったのだけど、なんか予言めいたツイートに見えちゃったのかもしれないけど偶然です。ここまで、いくつかの文化の変化がありました。 SourceForgeや
大人のスタートアップは大人のリリースができる。そう、ChatOpsならね。 | メルカリエンジニアリング
このブログをご覧のみなさま初めまして。@siroken3です。メルカリではインフラチームに所属しており、リリースの仕組み構築を担当しています。 メルカリのリリースについて メルカリではカスタマーサポートから受け取る改善要望、プロダクトとしてまだやれてないことなど多くのタスクがあり現在も継続して開発とリリースが行われています。 Issue管理はRedmine、ソースコードのリポジトリはGitHub privateを使用しています。Pull Request(以下PR)でのコードレビューを実施、masterブランチへマージされたものをリリースするのが基本的なフローです。 一方、1年前まではリリース頻度は週1回のリリース日を決めて実施していましたが、この1年で大きく変わりました。現在では日本版とUS版を合わせて10回〜30回/日の頻度でリリースしています。この記事では大きく変わったメルカリのリリー
1443641775
よく「どうやって情報手に入れてるの？」みたいに聞かれますが、そんなの、ひたすら時間かけてgithubみたりメーリングリスト読んだり最近ではgitterの会話読んでるに決まってます。 どうやって(How)ではなく、なぜ(Why)、自分がそんなことをするようになったのかを、あらためて書いてみる気になったので書いてみたいと思います。 書こうと思ったのは、Howだけ書いても、Why書かないとあまり意味ないと思うことが多くなったからですかね。(この件に関しては) 無責任に大雑把にいうと、(どんな理由であれ)情熱みたいなものがあれば、Howは自然に身につきます、たぶん。 なお、少し長くなるし、自分語りっぽくなるし、いつも書いてるようなものとは少し方向性が違い、具体的なすぐ役に立つ技術的な内容*1は基本出てこないので、期待してるものが違うと思う人は、ここで読むのやめたほうがいいと思います。 どれほどコー
プログラマの履歴書
「コードを書け。それが履歴書だ」という昔の名台詞が目に留まったので、常日頃感じていることを書き出してみることに。 コードが GitHubで公開してあると、まず採用する側の視点としては非常に助かります。プロジェクトを２、３つ眺めるだけでも、この人が普段どんなことを意識してプログラミングしているのかが見えてきます。例えば、性能を重視しているとか、拡張のしやすさを意識してインターフェースをデザインしているとか。さらに本人の興味の方向性、得意な言語などがわかるが何より嬉しい。過去の経験から、自己申告でJavaができます、C++ができますなどと言うだけの人が期待したレベルでコードを書けた試しがありません。 その次にわかるのがコミュニケーションスキル。基礎的な英語力の判断材料にもなるし、チームを組んだ時のイメージがしやすい。問題を共有する能力も大事。自分一人の頭の中でたくさん難しいことを理解して解決で
Scalaはなぜ難しいと言われるのか？ - たけぞう瀕死ブログ
Scalaをどうやって学ぶのがいいのか？ということはScalaを使い始めた数年前からずっと考えています。よく「Scalaは難しい」と言われますが、 どこが難しいのか？ なぜ難しいのか？ ということを、これまで書籍や雑誌記事、ハンズオンなど入門用のコンテンツを作ってきた経験を踏まえて整理してみました。 まず、Scalaが難しいといわれる理由のひとつに学ばなくてはならないものが多すぎるという点があげられます。Scalaはオブジェクト指向言語ですが、関数型言語の特徴的な機能を取り入れているため、きちんと理解するには両方の言語のイディオムを学ぶ必要があるためです。 ただ、Scala自体は必ずしも関数型言語の知識がなくても使えるように設計されています。最初はBetter Javaとして一般的な手続き型オブジェクト指向言語の延長として使い始めることができ、Scalaの特徴的な機能に触れていくことで少し
RE:統計的品質管理の功罪 - うさぎ組
概要 SNSで『統計的品質管理の功罪』というスライドについての意見を多数みかけたので、僕も読んでみたので感想を書きます。 ゆえに発表場所では多くのコンテキストが語られているかもしれませんが、スライドからはこう読めるよっていう感じです。 僕の感想は一言でいえば「タイトルは違うほうがいいし、SQCの勉強してないですよね？よく言えますね。」って感じです。 お酒飲みながらのLTだったらありかもーくらい。 もしSQCに村を焼き払われたという事情があるのであれば、SQCを徹底的につぶすくらいの非難なり、手法なりもってくるほうがよいのではないでしょうか。 つまり、マサカリ投げるなら徹底的に投げろ。 発端や背景 SNSで下記のスライドに対する言及が多数ありました。 統計的品質管理の功罪 from 工 久納 "辛いよねー"と共感するか、"コンテキスト広く言いすぎじゃないか？"と批判するかの2つが多かったよう
ScaleOut | Supership
2024年4月1日より、Supership株式会社は親会社であるSupershipホールディングス株式会社に吸収合併されました。 合併に伴い、存続会社であるSupershipホールディングスは社名をSupershipに変更し、新たな経営体制を発足しました。本件に関する詳細は、プレスリリースをご確認ください。 2024年4月1日より、Supership株式会社は親会社であるSupershipホールディングス株式会社に吸収合併されました。 合併に伴い、存続会社であるSupershipホールディングスは社名をSupershipに変更し、新たな経営体制を発足しました。 本件に関する詳細は、プレスリリースをご確認ください。
コードレビュー - hitode909の日記
コードレビュー，慣れるとできるけど，いきなりdiffを渡されて，どうぞ見てくださいと言われてもよくわからないと思う． やりましょうというのはいいけど，ただむやみに読んでもうまくいかない．変更がある程度大きくなるとdiffだけ見てもよくわからないので，いろいろ見ることになる． 僕はいつも以下のようなことを無意識にやってて，うまくいってる気がしてる．GitHubのPull Requestの仕組みを使ってる前提で． Discussionをさらっと眺めてどういう問題を解決したいのか見る Commit Statusを見て，テスト通ってることを確認する Commitsタブで1コミットずつブラウザの新しいタブに開く 全部クリックし終わったら古い順に1コミットずつ読む 気になる点があったらエディタとかにメモしておく．あとで書き直されるかもしれないので，まだコメントしない 全コミット見終わったらFiles
WIPであろうと、情報共有すると何がいいのか？ - ppworks.jp
口頭で話したことを文字に起こすことについての続編のような記事です。 消え行く知見や、消え行く情報を文字にすることで永続化させ、密室の議論を無くす。その為に以下のような活動が重要という話を書きました。 口頭で相談したことをesaやqiita:teamにまとめる 口頭でコードレビューしたことをgithubやgitlabのコードレビューのコメントにも書き残す 口頭で話したことをチャットにも書き残す チャットで話しかけた後に口頭で済んだ場合、チャットに解決済と流す 情報共有すると何がいいのか？ 何がいいか。 暗黙知を減らすことが出来る 当事者に なろうと思えばなれる なろうと思えばなれるというのは、どういうことかというと、共有化された情報は、その情報をどう捉えてどう向き合うか情報を得た側が選択してこそ価値が出る。 共有された情報に対して当事者意識を持つかどうかは情報と向き合った人に委ねられるという
クックパッドモバイルアプリの開発体制とリリースフロー - クックパッド開発者ブログ
こんにちは、技術部モバイル基盤グループの @slightair です。 今回は、クックパッドのモバイルアプリをどのような流れで開発しているか説明したいと思います。 この記事では技術的な話ではなく、どのようにして、どのようなことを考えて僕らがモバイルアプリを開発しているかに触れたいと思います。 開発体制 クックパッドにはモバイルアプリを専門で開発するようなチームはありません。 必要に応じて、誰でもモバイルアプリ開発に取り組みます。 機能追加・修正を行ったらリポジトリにプルリクエストを送ります。 プルリクエストが来たら、アプリ開発を行うエンジニア同士でレビューします。 様々な修正をひとつのバージョンにまとめるのは、僕が所属する技術部と後述するリリースマネージャーで行います。 リリースマネージャー バージョンごとに、そのリリースの責任をもつリリースマネージャーをひとり選びます。 リリースマネージ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
ログイン - はてな
