Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                

タグ

developに関するopparaのブックマーク (12)

  • 変化するフロントエンドエンジニアの役割。「モダンフロントエンド」開発組織のつくりかた | POSTD

    POSTD読者の皆さんはじめまして、メディアでキュレーターを担当させていただいている古川陽介と申します。 株式会社ニジボックスでデベロップメント室室長を務める他、株式会社リクルートでプロダクト開発部署のマネージャーも兼務しています。 また、Japan Node.js Associationの代表理事として、Node.js の普及を目指す活動なども行っています。 私が普段の仕事や活動の中で強く感じているのは、フロントエンドエンジニアの役割が大きな変換点を迎えているということです。 端的に表現するとスマートフォンの登場をきっかけとしたデバイスの多様化によって、フロントエンドエンジニアの領域が拡大したと言うことになると思います。 パフォーマンスや開発の生産性を著しく上昇させる、ReactVueを駆使したモダンフロントエンド開発と、それを実現するための組織構築は、今後のサービスやプロダクト開発

    変化するフロントエンドエンジニアの役割。「モダンフロントエンド」開発組織のつくりかた | POSTD
  • 1つでも該当すると、「会議の成功率」は5分の1以下 AIが導き出した、会議の成功を阻む5要素 | ログミーBusiness

    働き方が多様化した時代にも柔軟に対応し、最短距離で成果を最大化する「チームマネジメント」について、3回にわけて特集した株式会社SmartMeetingと株式会社SmartHRのセミナー。 記事では、「成果を上げるための会議」をテーマに、『超・会議術~テレワーク時代の新しい働き方』の著者・越川慎司氏が登壇した、3回目のセミナーの模様をお届けします。日企業における労働時間に占める社内会議の時間割合や、「会議の成功」の定義、そして会議でアウトプットが出ない理由など、さまざまなトピックが語られました。 延べ17万人超の労働時間を減らし、売上を上げる支援越川慎司氏(以下、越川):クロスリバーの越川でございます。はじめの40分で「815社に対応してきた会議データの実情」と「質と量を改善するためにどうしたらいいのか」といった資料を共有させていただきます。「こうやったらうまくいくよ」ではなくて、実例で

    1つでも該当すると、「会議の成功率」は5分の1以下 AIが導き出した、会議の成功を阻む5要素 | ログミーBusiness
  • 「何を言っているのか分からない」と言われないための「伝え方」のノウハウ - Qiita

    Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 0 記事の最重要ポイント 記事がストックの墓場に行ってもいいように、記事の最重要ポイントだけ先に伝えておきます。 質問に答える時は、聞かれたことにシンプルに答える。 事実と解釈を分けて話す。 1 記事で伝えたいメッセージ 1-1 コミュニケーション能力の苦手意識はノウハウで解決する ITエンジニアの裾野が広がるにつれて、SNSでも「コミュニケーション能力の低いITエンジニア」の話題をちらほら見かけるようになりました。いわく「これからはITエンジニアにもコミュニケーション能力が求められる」「プログラミングができるだけでは生き残れな

    「何を言っているのか分からない」と言われないための「伝え方」のノウハウ - Qiita
  • Puppeteer | Puppeteer

    Puppeteer is a JavaScript library which provides a high-level API to control Chrome or Firefox over the DevTools Protocol or WebDriver BiDi. Puppeteer runs in the headless (no visible UI) by default Get started | API | FAQ | Contributing | Troubleshooting​ Installation​ npm i puppeteer # Downloads compatible Chrome during installation. npm i puppeteer-core # Alternatively, install as a library, wi

  • Pipenv+LocalStackで作るLambda開発環境 | フューチャー技術ブログ

    はじめにこんにちは、TIG/DXユニット所属の宮永です。 PipenvとLocalStackを使用したLambda開発環境の構築を紹介します。 記事で作成するデモアプリは以下のGitHubリポジトリに格納しています。ご参考にしてください。 https://github.com/orangekame3/pipenv-lambda記事で伝えたいこと】 記事で最も伝えたいことはデプロイパッケージと開発パッケージの分離です。 Pipenvを使用することでzipの容量を節約しながらLambdaをデプロイすることができます。 やや長い記事となっていますので、「LocalStackへのデプロイ」の章だけでも見ていただけると幸いです。 PipenvとはPipenvはパッケージ管理ツールです。似たようなツールにPoetry等があります。 Poetryを使用したPython開発環境の構築は澁川さんの

    Pipenv+LocalStackで作るLambda開発環境 | フューチャー技術ブログ
  • 開発合宿をリモートで実施する工夫 - Hatena Developer Blog

    はてなでは、日々の業務を離れて興味のある技術を検証したり、開発の課題解決についてチャレンジする場として、開発合宿を定期的に開催しています。 以前の開発合宿では、貸し会議室を借りて参加メンバーが一カ所に集まり、集中できる環境を作って成果を出すことがポイントでした。しかし、新型コロナウィルス感染症の影響により、これまで通り同じ場所に集まって合宿を開催することが難しい状況になりました。 また合宿の意義は成果だけでなく、普段は業務上関わりがないエンジニア同士の交流の場にもなっていたので、コロナ禍でも継続して開催したい思いがあります。そこでリモートで開発合宿を行い、一カ所に集まらなくても合宿の体験を得られるようにしようと試みました。 これまで6月と9月の2回開催し、うまく実施するための工夫や課題が見えてきました。ここでは過去2回の振り返りをもとに、リモートでも開発合宿をうまく行えるようにする工夫を紹

    開発合宿をリモートで実施する工夫 - Hatena Developer Blog
  • サーバーアプリ開発環境(Python/FastAPI) | フューチャー技術ブログ

    Pythonでお仕事する前提で、現在のところで自分が最適と考えるチーム開発のための環境整備についてまとめてみました。今までももろもろ散発的に記事に書いたりしていたのですが、Poetryで環境を作ってみたのと、過去のもろもろの情報がまとまったものが個人的にも欲しかったのでまとめました。前提としては次の通りです。 パッケージ管理や開発環境整備でPoetryを使う 今時はコードフォーマッター、静的チェックは当たり前ですよね? コマンドでテスト実行、コードチェックとか実行とかができる(CI/CD等を考えて) VSCodeでもコマンドで実行しているのと同じコードチェックが可能(ここコンフリクトすると困る) デプロイはDockerイメージ コンテナのデプロイ環境でコンテナに割り当てられたCPU能力を比較的引き出せて、スケールさせたら線形にパフォーマンスアップできるようなasyncioを前提とした環境構

  • 「遅れ」なんてない - 日々常々

    「頑張って遅れを取り戻す」 綺麗な言葉ですが、私は嫌いです。その中でも次の言葉が特に嫌いです。 頑張る 遅れ 取り戻す 全部。これらが嫌いな理由をそれぞれ説明していきます。順番は「頑張る」→「取り戻す」→「遅れ」です。 なお、「頑張って遅れを取り戻す」に期待される結果は「他に一切の影響を与えず、遅れだけが綺麗になくなる」だと思われます。 頑張る 「頑張ってなかったん?」と言うと「頑張っていましたが、もっと頑張ります。」みたいなのが返ってきます。でもこれって多分「頑張る」と言われることが求められているからそう返してるだけで、もともと手なんて抜いていない。仮に手を抜いていたとしたら「頑張る」は「手を抜いていました」の宣言になるので、それを許容してる状態が問題になるんじゃないかな。 とか言葉遊びは置いておいて、現実の話をします。こういう文脈での「頑張る」は「長時間連続労働」に他なりません。そこで

    「遅れ」なんてない - 日々常々
  • How we ship code faster and safer with feature flags

  • どうして作りたいソフトウェアが伝わらないのか【後編】 | mah365

  • はてなブログチームの開発フローとGitHub

  • ふだんの開発で小さなPRに分けるために考えていること - 私が歌川です

    ふだんの開発でPRを出すときに考えていること - 私が歌川です の続編です。小さなPRを出す、という話がありましたが、どうやって小さくしているのか、というのを書きます。 どういうメソッドが欲しいか考える Aという情報をBという画面に出したい Aを取得するメソッドがないので、それを作る必要がある (メソッドCとする) というときに、メソッドCを作るPRをまず先に出して、マージされたら続いてCを使って得られる情報Aを画面Bに出すPRを出す、というのをやります。 実装方針を考えて既存実装を眺めてからそういう作戦を立てることもあれば、実装しているうちにメソッドCが足りないな、と気づいて別ブランチでPRを作ってそちらを先に出す、ということもあります。 このとき、1つのPRで両方やろうとすると、メソッドCの実装のレビューと、情報Aを画面Bに出す実装のレビューが同じPRで行われることになります。メソッド

    ふだんの開発で小さなPRに分けるために考えていること - 私が歌川です
  • 1