タグ

開発に関するperlbombのブックマーク (16)

  • 信用できる社内 Wiki をつくるために守ってほしい、たったひとつのルール - 無印吉澤

    このページについて この記事は、以前書いた「社内Wikiに情報を書くときに守ってほしい、たったひとつのルール」の続編です。前回は、個々のページをどう書くべきかという話をしましたが、今回は社内 Wiki 全体を信用できるものにする方法について考えます。 muziyoshiz.hatenablog.com 想定する環境 この記事は、ソフトウェア開発プロジェクトに関する Wiki が社内にあって、そこに各人がドキュメント(仕様書や手順書など)を書けるようになっている環境を想定しています。 私自身、ソフトウェア開発のときしか Wiki を使わないので、具体例もそのような環境に寄っています。ただ、ある程度は社内 Wiki 全般に通じる話かと思います。 ルール:「更新され続ける」ページと「更新されない」ページをはっきり分ける ここ1年ほど社内プロジェクトをいくつか渡り歩いていたのですが、個人的には、こ

    信用できる社内 Wiki をつくるために守ってほしい、たったひとつのルール - 無印吉澤
  • バグなどの謎の現象に立ち向かうも闇が濃く、どうしても沼から脱出できない時に見るフローチャート - Thanks Driven Life

    ご査収ください (2022年12月8日 追記) フローチャートを書き直しました。内容自体は当時のものと同じです。 補足 パフォーマンスの出し方は人それぞれなので「私はこんな感じです」というものです。 とりあえず「なんかやばいな?」と思ったら休む 体調的にはもちろん、「これ結構やばそうだな?」という勘所は大事 15分以上(長くても30分)悩んだら周りに聞いてみる こういう時はだいたい 視野が狭くなっている(簡単なスペルミスだったり) 暗黙知に触れている(業務だとよくある) とてつもない難問にぶちあたっている といったケースなので、仲間にSOSを出した方がチーム全体の進捗も結果的に良くなる、という経験談です。 ちなみに15分の根拠はなんとなくです。 ちなみに、問題に取り組み始めるその瞬間から「15分やってわからなかったら誰かに聞こう」としている場合は、 フローチャートの「30分動いてなかったら

    バグなどの謎の現象に立ち向かうも闇が濃く、どうしても沼から脱出できない時に見るフローチャート - Thanks Driven Life
  • 「実はDeployGateを一番活用しているのは、エンジニアではなくデザイナーなんですよ」DeployGate導入企業インタビュー・クックパッド編

    DeployGate 導入企業インタビュー クックパッド株式会社/加藤 龍 様 国内最大の料理レシピサービス「クックパッド」を開発・運営するクックパッド株式会社では、社内でのベータテストをより円滑に行うため「DeployGate Enterprise」が使われています。 同社が大切にする価値観「ユーザーファースト」を実現するアプリはどのように生み出されているのか、同サービスを開発するクックパッド株式会社の加藤 龍 様にお話を伺いました。 DeployGate 導入企業インタビュー クックパッド株式会社/加藤 龍 様 国内最大の料理レシピサービス「クックパッド」を開発・運営するクックパッド株式会社では、社内でのベータテストをより円滑に行うため「DeployGate Enterprise」が使われています。 同社が大切にする価値観「ユーザーファースト」を実現するアプリはどのように生み出されてい

    「実はDeployGateを一番活用しているのは、エンジニアではなくデザイナーなんですよ」DeployGate導入企業インタビュー・クックパッド編
  • project毎のnpmコマンドをいい感じにするnpmrc & config達 - Qiita

    npmrcのドキュメントを読みなおしていたら、.npmrcは/path/to/my/project/.npmrcのようにプロジェクト毎に配置することが出来る事に気づいて、ちょっと使ってみたら便利だった。 globalやhomeディレクトリへの設定を前提としたnpm configの記事は結構あるが、プロジェクト毎でnpm-configについて書かれている記事があんまり無かったのでまとめてみる。 npm-configの何が良いのか? project毎に出来ると何が良いのか? npm-configの設定をすると、色々コマンドを省略出来たりして良い事がある。 (参考:2016年版 Node.jsで幸せになれる10の習慣) npmrcやnpm-configは、個人開発用であれば、$HOME/.npmrcへの設定だったりnpm config setでの設定で十分。 また、npm registryに登録

    project毎のnpmコマンドをいい感じにするnpmrc & config達 - Qiita
  • レガシー開発環境を今風の開発に近づけるために一年やってきたこと - Qiita

    自己紹介 @pugiemonn といいます。 オンラインサロンプラットフォームを手掛けるシナプス株式会社で開発とマーケティングを担当しています。 今日の話 1年前にレガシー環境に参加したメンバーがレガシーな問題に対して、どのような取り組みを行ってきたかお話します。 開発チームメンバーゼロ問題 社長1人で3年開発していた 1人で走るのはつらい 突然ユーザー数が増加しはじめピンチに 求人がんばった結果 チームメンバー10名(インターン生含む)になりました✨ バージョン管理されてない問題 1人だったのでバージョン管理など無かった GitGithubを導入した結果 まずはSourceTreeから 作業ログがわかるようになった 問題発生箇所の調査が容易に 作業がチケット化されていない問題 1人だったのでチケットなど無かった 何のタスクかわからない チケット管理した結果 何の作業かわかるようになった

    レガシー開発環境を今風の開発に近づけるために一年やってきたこと - Qiita
  • http://post.simplie.jp/posts/34

    http://post.simplie.jp/posts/34
  • iOS アプリ作成入門

    KMC 春合宿 2016 // Android -> https://speakerdeck.com/nonylene/androidios-apurizuo-cheng-ru-men-android-bian

    iOS アプリ作成入門
  • 複数人でのWebサービス開発で便利だったもの - Qiita

    遊びに使えるWebサービス友人と一緒に作成中。 仕事じゃなかなか使えないようなツールやサービスを無料の範囲内で使ってみてるんですが、かなり便利。 忘れないようにまとめてみます。 なおJavaJavaScriptを使ってるので、それに関する内容が多いかも。 なお、次のような感じで開発進めてます。 週に1回集まってミーティング兼もくもく会 集まらない日は各自のペースで作業 機能などを作ったらプルリクエスト出して承認もらって取り込む サーバー側がJavaでクライアント側がJavaScript BitBucket Gitリポジトリをホスティングしてくれるサービス。 他にも類似サービスはいろいろあったけど、非公開リポジトリを無料で作れるってのが決め手。 基的にソースコードはここで一括管理して、各自が作った機能とかは必ずプルリクエストを出す運用で活用中。 ReadmeとかWikiも便利で、ここに

    複数人でのWebサービス開発で便利だったもの - Qiita
  • プロジェクトマネジメントは仕組み化が9割

    今回はオペレーションに関するスライドです。特にフォーカスすること、フォーカスするためにできることについて解説しています。 スタートアップへのアドバイスとして「フォーカスが大事」とよく言われます。それでも実際にフォーカスできているスタートアップは中々いないようです。 なのでこのスライドでは、なぜフォーカスすべきなのか、そして実際にフォーカスするためにどうやってオペレーションを効率化すれば良いのかなど、私がこれまで支援の中で得てきた知識をまとめてます。少しでも効率化して、フォーカスできるようになればいいなと願っています。

    プロジェクトマネジメントは仕組み化が9割
  • アプリケーションの設定はごめんだ! : アプリケーションのユーザビリティを考える | POSTD

    (訳注:2016/3/2、頂いたフィードバックをもとに記事を修正いたしました。) 注 このブログ投稿は不満をぶちまけています。かなりのものです。自説は曲げません。長いです。そして、頭に血が上っています。かなり暴言です。 目次 アプリケーションの中身は? アプリケーションについての考え方が間違っている アプリケーションは 体験 のようなもの この問題の解決策 1. 設定より規約 2. アプリケーションを使いながらユーザを丁寧に導く 3. 失敗は起こる。その直し方を知りたい 4. ドキュメンテーションについて考えるのは、やめよう まとめ 参考文献 最近、ソフトウェア開発において復活しつつあるとても 興味深い 傾向があるようです。おそらくNode.jsの哲学に影響を受けているのでしょう。何かを使うためには、まず大量の「依存パッケージ」をインストールする必要があり、さらにそのコンフィギュレーション

    アプリケーションの設定はごめんだ! : アプリケーションのユーザビリティを考える | POSTD
  • 巷で話題のDockerとは?

    Dockerが利用される背景 今、世界中の開発者やIT部門において「Docker」(ドッカー)が注目されています。もともと、DotCloud社(現 Docker Inc.)が、開発者やIT部門をターゲットとしたアプリケーションやOSの開発・配備を行うための基盤ソフトウェアとして開発され、2013年にリリースされました。このソフトウェアは、オープンソースソフトウェアの「Docker」として公開され、その使い勝手の良さから、多くの開発者、IT部門の管理者で瞬く間に利用されることになりました。Dockerは、仮想化ソフトウェアにみられるような性能面での劣化を極力排除したコンテナ技術の採用により、仮想化ソフトウェアに比べ、極めて集約度の高いITシステムを実現することができます。しかし、このDockerが注目される理由は、ハイパーバイザー型の仮想化ソフトウェアに比べてのハードウェア資源の消費や性能劣

    巷で話題のDockerとは?
  • 体に貼り付けられる体温計を開発 NHKニュース

    電気を通す特殊なインクを使って、体に貼り付けられる薄いシート状の体温計を東京大学のグループが開発し、医療分野などへの応用が期待されています。 グループでは、“電気を通すインク”のひとつとして、熱によって膨張する物質を加えたものをつくり、温度の変化にあわせて電気の通り方も変化させることに成功しました。 このインクを薄いプラスチックのシートに印刷すれば、印刷した部分が温度センサーとなり、体に貼り付けられる体温計の開発につながったということです。 この体温計は、誤差が1度の50分の1以下と高精度で、体のさまざまな場所に同時に貼り付けられることから、グループでは、手術後の患者で炎症による発熱が起きていないかチェックするなど、医療分野などへの応用が期待できるとしています。 研究グループの横田知之特任助教は、「材料はとても安く、印刷の方法も簡単なので、あと数年で実用化できるのではないかと思う。医療分野

  • 基本設計を分担してはいけない - 設計者の発言

    プロジェクトメンバーが無駄に多いのが、日型SIの特徴のひとつである。「工数を人数で割れば工期が出る」と考えることが間違いであることは、ブルックスの著書「人月の神話」によって今から40年前に指摘されている。それにもかかわらず、相変わらず多くのプロジェクトで必要以上の人数が投入されている。 私がとくに不思議に思うのが、基設計を何人もの要員で分担するやり方だ。DB設計と機能設計と業務設計の担当を分けるとか、サブシステム毎に担当を分けるといった体制がしばしば敷かれる。詳細設計の段階でというのならまだわかるが、基設計でそれをやってはいけない。 なぜか。業務システムにはアーキテクチャ(意図された構造)が求められる。そして、そこに含まれる膨大な定義要素は、統一感や一貫性を保ち、かつMECEな形で切り出されなければいけない。複数の要員で分担などすれば、それらの課題が一挙に難しくなる。また、DB構成と

    基本設計を分担してはいけない - 設計者の発言
  • プロジェクトを成功させるために最初におこなっていること - $shibayu36->blog;

    ディレクター時代に仕事プロジェクトを受け持つ時にどうやったら成功させることが出来るのかについていろいろ考えていた。僕は開発フローをいろいろ考えるのが好きなのだけど、実際に自分がリーダーシップを取ってプロジェクトを進めることを経験すると、そもそもその前に考える・決めるべきことがたくさんあるということが分かったので、ブログに書いておこうと思う。 ここで言うプロジェクトとはサービスを一から作ったり、サービスの一機能を作ったり、受託案件一つだったりを指す。特に開発プロジェクトに限定するものでもない。 プロジェクトを成功に近づけるためには、まずプロジェクトの開始時に、プロジェクトの5W1Hを明確にし、個々のメンバーの責任範囲を決め、それらを一つの場所にまとめておくということをしておくと良いと考えている。 5W1Hを決める すごい基的なことだけど、プロジェクトをやる上でやはり5W1Hは大事である。

    プロジェクトを成功させるために最初におこなっていること - $shibayu36->blog;
  • Electronでデスクトップアプリを簡単構築

    全国5000人のエンジニアをやめて寿司職人になろうと思っているみなさんこんばんは。 前回までスライド共有用のアプリケーションを趣味(リハビリ)で作っていたのですが、折角なのでデスクトップクライアントも作ってみました。 構築にはElectronを使ったのですが、結構簡単にできたので記録としてまとめておきます。 Electronって何?GitHubが開発するクロスプラットフォームで動作するアプリケーションを開発するためのフレームワーク。コードの記述はHTML5とNode.js。その範囲であれば既存のWeb開発技術が使いまわせる。例えばjQueryとかAngularなんかを使うのも可能Chromeブラウザのオープンソース版のChroniumのエンジンを内蔵例えばAtom・Visual Studio Code・Slackクライアントや、日だとKobitoあたりがメジャー作り方あちこちに記事があが

    Electronでデスクトップアプリを簡単構築
  • 動画で学ぶモダンなiOS/Androidアプリ開発技術 - ainameの日記

    iPhone6sとiPad Pro発表されましたね。早くXCode7をstore配布して欲しいです。 スクラムチームで属人化させずにiOSもAndroidRailsAWSも全部やっていく話 - ainameの日記 この記事で、スマホアプリのチーム開発のことを書こうと思って先週はちょっとリリース前とか飲み会で忙しかったのであまり手がついておらず、どうやって書いてくかを考えてはいたけれど書いてこうとすると大分壮大になっていくので、ひとまず日常的な行いを少しづつ書きためていき、リンクで参照できるようにしておくことにした。 ということで今回は、社内で最近行っているプラクティスというか勉強手法で、動画でスマホアプリの技術を学ぶ方法を紹介する。 動画で学ぶ 近年、Youtubeとか動画配信環境が良くなったおかげで各種技術系カンファレンスの発表が綺麗な画質でネット上に公開されている。 特に海外のカン

    動画で学ぶモダンなiOS/Androidアプリ開発技術 - ainameの日記
  • 1