質問は恥ではないし役に立つ - Qiita
一年半SEとして働いてきた中で、私自身が苦手だと思っており、他人からもそのように評価されていたのが「質問の仕方」でした。 それが先日、他人から「質問の仕方がうまいね」と褒められることがあり、ようやく一人前の質問の仕方ができるようになってきたので、どのようにして克服できたのか紹介したいと思います。 質問の基本形 私が入社したばかりの頃は、わからないことがあればすぐに先輩に質問していました。 そのときにしていた質問の内容はだいたいこんな感じです。 「環境構築を手順書通りにやったんですけど、○○のコマンドでエラーがでてしまいます！なんとかなりませんか？」 このような質問を受け取ったら、先輩は暇ならばエラーメッセージを見てくれ、エラーメッセージに書かれていることに対して調査してくれるかもしれませんが、忙しいときにはそんなことはしてもらえません。 こんな質問を繰り返しているうちに先輩からは「技術系メ
はじめに みなさま、こんにちは！年末の忙しい時期ですが、お元気ですか？ 僕はなんとか元気です＞＜ 使っていた PC を壊してしまったので Windows7 搭載マシンを買ってきましたので、購入から初期設定、便利なアプリのインストールまでここにメモしておきたいと思います！ 購入まで と言うことでまず購入までにやったことをまとめてみたいと思います 価格.com で調べる まずは、価格.comを使って、以下の条件で良さそうなパソコンを探してみます。 8 万円以下の価格 それなりのグラフィックボード（最近 Minecraft っていうゲームをやってるので） それなりのメモリ（メモリ安いので） それなりの CPU USB 3.0 （データ移行のときにハードディスクを USB 3.0 でつなぎたいので） ディスクアクセス速度は、ある程度遅くても良い（RAM ディスクで頑張る戦略） 買うパソコンを決める
新人にパワハラしていた先輩を通報した結果
パワハラしていた先輩＝Aさん パワハラされていた新人＝Bさん Bさんが入社したのは2021年1月。 3月で退職する社員がいて、その後釜だった。 前任者から引き継ぎを受けた後は、Aさんがサポート係になってペア組んで仕事してた。 Aさんのパワハラっぽい行動が目立ち始めたのは、たしか2021年の秋ごろ。 「それ何回教えたら覚える？」という言葉が頻繁に聞こえてくるようになった。 Bさんが何か質問すると「マニュアルに載ってる」「自分で調べなさい」「前回教えたときにメモしてなかったの？」と突き放すような言動が目立ち始めた。 そうやって突き放すわりに「なんで勝手に判断した？こっちに確認してから動いて」みたいなこともよく言っていた。 Bさんの仕事の覚えが悪いことは何となく察していたが、それにしたって言いようがあるだろと思っていた。 だんだんとAさんの態度はきつくなっていって、部署の雰囲気が悪くなっていった
大学や大学院で論文の書き方を鍛え上げた人たちには遠く遠く及ばないが、僕の様なはぐれもの1でも最近は Amazon 社内で文書の質が高いと評価してもらえるまでにはなった。Software Engineer として、コードでのアウトプットはもちろん大事だけど、文書のアウトプット(およびそれによって得られた実際のアウトプット)は同じだけ重要である2。今回は自分が最近どういうところに気をつけて技術文書を書いているのか、ということについて数年後の自分が忘れてないことを確かめられる様にまとめておく。 そもそも文書とは？ 英語だと document。ここで指す(技術)文書とは、人間が読む文体で書かれた技術に関連する情報、といったものだ。具体的に言うと以下の様なものを想定している: 新しいプロジェクトの骨子を説明する資料 会議の叩き台となる 1 枚ペラ 本番環境に変更を加えるにあたっての包括的な情報や具体
はじめに ちょっとつぶやいたら思いのほか需要がありそうだったので、簡単にまとめておきます。 おことわり これを書いておけば、すべての不幸を避けられるというものではありません 提出先との関係性次第では、書かないほうがいいこともあるかも 私自身が普段提案している内容が、すべて記載されているわけでもありません（うろ覚えで書いてたり、大人の事情） これを流用しておこったすべての事項について、何らかの責任をとることはできません 本稿では請負による開発を想定しています でも共有することで、この業界の不幸が減ればいいなということでつらつら書いてみます。 他にもあるようなら、Twitterなりコメントなりで提案してもらえると嬉しいです。 前提条件を書く目的 見積・提案書通りに、実施するために必要な条件を明確にする 条件を逸脱したときに、どうなるのかハッキリさせる 上記は概ねつぎのとおり 実現が不可能になる
少し気が早いですが、今年も残すところ あと僅かです。ここで、Web制作をする にあたって、個人的に、とても参考にな った素晴らしいエントリーをご紹介します。 基本的にまとめ記事が大好物なので、 まとめのまとめ、という形になってしまい ますがご了承願います。 まぁ、単なる個人的なメモです。今年はお世話になりました、という感謝の意を込めてリンク&トラフィックで返したいのと、自分の復習用リンク集です。来年もたぶんお世話になる記事だと思いますので、備忘録も兼ねて。順不同です。 尚、当ブログのエントリは御礼の場であるこの記事では割愛しています。後日、別記事にてまとめさせて頂きますので、宜しければ御覧ください。 デザイン 読み物系が多いです。正月とかで見直す用。 配色パターンからWebデザインを考える ウェブデザインでこれは気をつけたいの35のポイント デザインQRコードの作り方 非デザイナーのための
私自身、物事を分かりやすく伝えるスキルを身に着けるため、手あたり次第に、いくつかノウハウ本を読んだり、YouTube動画を観たりしてきました。本記事では、本や動画から得られたノウハウや、私が普段の仕事で発見した個人的に使っているテクニックをまとめてみました。 0 本記事の最重要ポイント 本記事がストックの墓場に行ってもいいように、本記事の最重要ポイントだけ先に伝えておきます。 質問に答える時は、聞かれたことにシンプルに答える。 事実と解釈を分けて話す。 1 本記事で伝えたいメッセージ 1-1 コミュニケーション能力の苦手意識はノウハウで解決する ITエンジニアの裾野が広がるにつれて、SNSでも「コミュニケーション能力の低いITエンジニア」の話題をちらほら見かけるようになりました。いわく「これからはITエンジニアにもコミュニケーション能力が求められる」「プログラミングができるだけでは生き残れ
インフラについて、何となく理解しているつもりでも、「インフラとは何か？」と聞かれると、こういうものであると明確に答えるのは案外難しいものです。 そこで、インフラの基礎がわかるスライドシェアを10個ピックアップしてご紹介します。 インフラエンジニアの定義、インフラの基礎、手順書の書き方、インフラ自動化など、初心者から中級者向けの内容となっています。 Web業界で働くなら、システムの基盤となるインフラについて学んでおいて損はないはずです。
創作論とか小説の書き方みたいな本について言うと、作家やその周辺の人が書いているせいか、かつてはその困難さを前面に掲げて、結果的に創作行為の神秘性を保守する手合が多かった。 近頃は「誰でも書ける」みたいなのも随分増えたけれど、タイトルだけ付け間違えたようなのが多くて、あいかわらず、もったいぶった文士臭さが抜けてない。 探す場所を間違えたのだと考え、はなっから「創作行為の神秘性」なんて受け付けない人たち向けに書かれたものを探した。つまり子供向けである。 学校の課題になったりするせいか、アメリカのものに、手続きだけに注力した実にアッケラカンとしたのが多かった。 ネットでフリーで手に入るものだと、National Novel Writing Month（通称：NaNoWriMo ※）のYoung Writers Program用ワークブックが、ほぼ同じ手続きを小・中・高校生向けの３種類に書き分けて
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? おしながき メンバーは3〜5名、協力企業は1〜2名の小規模チーム メインは某小売店の大規模ECサイト案件統括（開発は外部委託） サブで基幹連携等を担う周辺業務システム開発・運用 マネジメントが上手く回らず高残業が常態化。PM前任者異動に伴い、部下だった私にお鉢が回る 上長指示により残業削減へ そんな2〜3年前のお話です。 改善"前"のタスク運用 ※あくまで改善"前"の話です。 基本はRedmine + Kanbanプラグインでタスク（チケット）運用。 ナレッジ可視化の意識付けも目的の一つだったので、以下を徹底した。 作業に伴うタスク発行
GoFデザインパターンの一覧表と，活用のためのコメント，および入門者が独学するためのリンク集（サンプルコード付き）。 入門者の独学を支援するために，このページのURLを提示して熟読させ，各パターンを短時間で効率よく学んでもらう。 デザインパターンはプログラマの常識だ。 Java使いかどうかは問わない。 にも関わらず，入門書を買ったまま，途中で挫折する人が多い。 挫折の原因は，パターンの数が23もあって，多いからだろう。 全パターンをすんなり覚えてもらうためには，各パターンごとに 「要するにこういう目的のパターンなんだ。」 「10文字で表現すると，パターンの意味はこうなんだ。」 という要点・本質を，短いコメントで伝えれば助けになるだろう。 こういった学習を通して，Java言語の「設計思想」も併せて感じ取ってゆけるはず。 全パターンの一覧表（要約コメント付き） 全パターンについて，10文字以内
独身男性 新築を買う
家賃と駐車場代払ってると駐車場付きの家欲しいなる — 不動産取得税申告 (@mzyy94) November 29, 2020 都内で月極駐車場を契約して賃貸マンションに住まう総居住費に対し、駐車場付き物件を住宅ローンを組んで支払う方が、税金や月々の返済を考えても安上がりなことを第一の理由に、この2023年に家を買うことにした。当初は一切のこだわりがなく、とにかく家を買って住むぞという軽い気持ちだけでスタートしたので、そのスタートからゴールまでの経験や過程を記事にする。 目次 Open 目次 家選びの条件を狭める Q. マンションか一軒家か 1. 駐車場利用料と車庫サイズ 2. 管理費と自治 3. ゴミ出し体験 Q. 中古か新築か 1. 住宅ローン控除の還付額の差 2. 契約不適合責任の範囲 3. 不動産取得税と固定資産税など各種減税 Q. 建売住宅か注文住宅か Q. 借地か所有権か ここ
賃貸物件を探すのに不動産屋さんは使えない - Money does not hurt your heart
引越にまつわるメモ目次 引越プロジェクト発動 - tittea blog 賃貸物件を探すのに不動産屋さんは使えない - tittea blog 賃貸物件を探すときに不動産屋さんに伝える条件 - tittea blog 賃貸物件の契約書で気になっていること - tittea blog 引越の合い見積もり2回目 合い見積もりは分けて取るのがよい - tittea blog 賃貸情報サイトの釣り物件？ - tittea blog 賃貸 部屋を借りるときに建物の登記簿を取ってみた - tittea blog 不動産屋さんへ直接行って物件を紹介してもらう時代は終わった？ もう、不動産屋さんへ行かないと物件が見つからない時代は終わりつつあるんじゃないだろうか。 10年前に引越をしたときには、まだネットではChintaiぐらいしかサイトが無くて、サイトへの情報の反映も遅くて、実際に不動産屋さんへ行く価値
はじめに この記事は、エンジニアがどのように技術を学べば良いのかということについて、おもに西尾泰和氏の書籍・記事で主張されている内容を元に、特定の問題を対象として自分の考えを加えて考察したものです。特定の問題としては、以下の3つを設定しています。 何を学べば良いのか分からない 技術書を読んでもすぐ忘れる 学習する時間がない もちろん、学ぶ上で考えるべきことは上記の問題にとどまりませんが、ここでは、比較的身近で耳にすることが多いと感じるものを問題として設定します。 定義 この記事ではスコープを特定の範囲に限定しているため、一般的な用語について、一部を以下のようにローカル定義しています。そのため、一般的な用語そのままの意味においては、この記事の内容はコンテキストを維持できないことがある点に注意してください。 エンジニア Web 系企業に勤めており、主にプログラミングをはじめとしたコンピュータサ
リスクの洗い出しと判断のコツ - やしお
会社で係長的なポジションになって3年近くが経った。先日、副係長というか職長的なポジションが新たに設けられ、30歳前後のメンバーが就いた。折を見て彼らに伝える機会があるかもしれないし、3年やってみた知見を自分の中で一度整理しておきたいと思った。（大手メーカーの製造側に近い部門で働いている、という前提がある。） 自分が苦しくならないようにする 究極的には本人が自分でスタイルを確立するしかない。 「こうした方がより良い」と思って行動変容しても、それで自分が苦しくなるなら続けられない。 どうせ正解の型が一意に決まるわけではないし、仮に正解の型があっても自分を完全にはめ込むこともできない。 「自分がやれるようにやるだけ」くらいに思っている方が精神衛生に良い。それで不適格ならしょうがない。 一方で「より良い方法」に寄せる努力も必要で、その間のバランスが必要になる。 例えば自分自身は、人付き合いがすごく
この記事は下記のURLにあるコミックマーケット90で頒布した同人誌と自分が管理するブログの記事を微修正し、転載したものです。 南関東開発機構 : 同人誌「日本の行政機関が公開中のAPIについて調べてみた本」を公開しました http://blog.livedoor.jp/south_kanto_dm/archives/52143201.html 南関東開発機構 : 日本の行政機関が公開中のAPIについてのまとめ（2016年8月17日暫定版） http://blog.livedoor.jp/south_kanto_dm/archives/52143463.html 前書き この記事の目的は、日本の行政機関等が公開しているAPIを紹介する事です。 日本の情報技術は他国と比較して、立ち遅れている部分があり、これを立て直すのが喫緊の課題であると言えます。 日本政府もこの問題に危機意識を持ち、先日、経
はじめまして。2019年1月に入社したSREスペシャリストのsonotsです。最近MLOpsチームのリーダーになりました。今回の記事はMLOpsの業務とは関係がないのですが、3月に弊社で実施した会社用GitHub個人アカウントの廃止について事例報告します。 TL;DR 会社用GitHubアカウントを作るべきか否か問題 会社用GitHubアカウントの利用で抱えた問題 1. OSS活動時にアカウントを切り替える必要があり面倒 2. GitHubの規約に準拠していない 会社用アカウントを廃止した場合にセキュリティをどのように担保するか GitHubのSAML single sign-on (SSO)機能について 会社用アカウントの廃止およびSSO有効化の実施 会社用GitHubアカウントを使い続ける場合 私用GitHubアカウントに切り替える場合 Botアカウントの場合 Outside Coll
みずほ銀行システム障害に学ぶ
みずほ銀行システム障害の調査報告書が公開されたのがニュースになって、Twitterなどで色々な人がコメントをしているのを見た。140文字しか書けない空間で他人の失敗談の揚げ足取りをするのは簡単だが、そこからは一時の爽快感以外に何も得るものがないので、僕はそういうのはカッコ悪いと思っている。 そこで、ちゃんと読んでみたら全く他人事でない部分も沢山あるし、非常に面白く勉強になったので、ブログにまとめてみる。 技術的な話 銀行のシステムがどのようになっているのか、全然イメージが湧いていなかったので、それがまず勉強になった(p.29)。 トラフィックのソースに応じて用意された色々なシステムから基幹システム「MINORI」の取引メインバスにトラフィックが流れ、そこから各種システムへとリクエストが送られていく。この辺はService Oriented Architectureらしい。開発当時としては（
はじめに こんにちは植木和樹＠上越妙高オフィスです。本日は私がここ10年くらい意識している運用手順書を書くときのポイントについてまとめてみました。 対象読者 開発・構築したシステムを別の人に引き継ぐ予定のある人 他の人が作ったシステムを引き継ぐ担当の人 半年後の自分でも分かる手順書の書き方に困っている人 （この記事を読むのにかかる時間の目安：5分） 1. ドキュメントの冒頭に書くこと まず個々の詳細手順の前に、ドキュメント自体について記載してもらいたいことです。 1.1. ドキュメントに書かれていることを3行で書く ドキュメントの最初には、このドキュメントに何が書かれているのかを100文字くらいで書いておくと良いでしょう。 システムが増えれば増えるほど手順書も増えていくものです。見つけたドキュメントに自分の期待するものが書かれているのか、冒頭数行でわかるようになっているとうれしいです。 1
2022年7月2日、設備障害によりKDDIの携帯電話サービスで障害が発生しました。ここでは通信障害に関連する情報をまとめます。 通信障害発生から復旧発表まで3日以上 au携帯電話サービスがご利用しづらい状況について 障害発生同日8時以降から1時間おきに障害報告が公表されていた。 障害発生・復旧の状況は以下の通り。 対象地域 障害発生日時 復旧作業終了時間 復旧完了日時 西日本 2022年7月2日 1時35分頃 2022年7月3日 11時頃 2022年7月5日15時36分 東日本 2022年7月2日 1時35分頃 2022年7月3日 17時30分頃 2022年7月5日15時36分 影響を受けたのは全国の個人・法人向けのau携帯電話、UQ mobile携帯電話、povo、au回線利用事業者の音声通信、ホームプラス電話、ホーム電話、auフェムトセル、SMS送受信。7月3日11時時点の概算では約3
modules: jmeter: version: 5.4.1 # ここに書いてあるバージョンを勝手にダウンロードしてくれる properties: log_level.JMeter: WARN log_level.JMeter.threads: WARN system-properties: org.apache.commons.logging.simplelog.log.org.apache.http: WARN 既存ツールのラッパーとして動作 デフォルトでは内部的にJmeterが実行されますが、以下のようなツールで作成されたスクリプトを流用することが可能です。 JMeter Gatling Locust Selenium Vegeta つまり、さきほどはYAMLでシナリオが記述可能とは言いましたが、もちろん既存のスクリプトを流用できるってことです。 いままで作り上げてきたスクリプトや
ホーム > マンションの大規模修繕で取り回しやってたら、何故かslackで業者さんの業務改善までやることになってたでござるの巻 ぶち大変でした。 しんざきが住んでいるマンションでは、住人持ち回りで管理組合の役員が回ってきます。 実は先日まで、しんざきは管理組合の理事長でした。 それ自体は順番なのでしょうがないんですが、運が悪いことにたまたま大規模修繕実施の年であり、しんざきは色々な調整やら手配やらをすることになりました。 マンションの大規模修繕というのは、十年くらいに一度、壁の塗り直しやら傷んだ建物の修繕やらをやる作業です。 数百万から数千万くらいの結構な費用がかかる話で、日ごろ住民が納めている管理費用の中から、大規模修繕費用というものを積み立てています。 大きなお金が動く話ですので、色々な人が色々な希望を持ちますし、業者との折衝もしなくてはいけないですし、家庭によって熱意は違いますし、納
とある日、辞令が下された。 ある人（勤め始めて5年以上は経つ）が私の所属している部署に異動してくるという、一見なんでもない辞令だった。 しかし、部署内の空気は重かった。 なぜなら、彼はもう3部署も飛ばされている、言わば問題児だったからだ。 Aさんの始まり 彼の武勇伝は、彼が入社した当時にまで遡る。 研修も終わり、配属先が決定した当日、伝説となる発言を放ったのだ。 ｢私は発達障害持ちです。フォローをお願いします｣ 配属先である部署の人達は、唖然としたという。 なぜなら、彼は正社員雇用だったからだ。 弊社では障害者雇用も行っているため、そういった方々も多少は採用されている。 しかし、クローズで正社員雇用をすり抜けた挙句、雇用が本決定した途端に告白し、開口一番こちらからのフォローを求める発達障害者は初めてのケースだった。 障害者雇用であれば先例があるためこちらも動きやすいし、せめて面接時に｢発達
監視という一種マニアックな領域を真正面から解説した貴重な本です。監視で悩む人のみならずシステム開発に携わるすべての人にオススメ。 「全然わからない。俺たちは雰囲気で監視をやっている」 自分はAWS事業本部コンサルティング部所属ということもあって、いろんなお客様にAWSインフラのコンサルティングしてます。最初のインフラ構成設計時に監視の話をすることも非常に多いんですが、 「どうしましょう。CloudWatchでいけますかね？」 「MackerelとかDatadogとかもありますが、どうしましょ。マネージドとの違いは〜」 「とりあえず、ディスク使用率80%でしきい値設定しておきましょうか。みんなそうしてますよ」 とか言っていた昔の自分に見せつけたい本、それが今回紹介する「入門 監視」。 監視設計の原則がよくわかんない メトリクスのしきい値決めるところから監視を考えてしまいがち よく考えずに、い
無駄な思考と行動を激減させる、科学的に裏付けられたスゴイ方法 - ふろむだ＠分裂勘違い君劇場
考えてもしょうがないことを、何度も繰り返し考えてしまうこと ってありませんか？ やるべきことがたくさんあるのに、それほどやりたいわけでもないゲームやネットをダラダラやってしまうこと ってありませんか？ そういう無駄な思考と行動を減らせれば、 人生は、もっと、ずっと豊かになると思いませんか？ 僕の場合、そういう無駄な思考と行動を減らすのに、 今までで、一番、コスパが良かったのが、 いわゆる、第三世代の行動療法のACTでした。 行動療法？ 医療機関でやるの？ めっちゃお金と時間がかかりそう。 いやいや、ぜんぜん、そんなことないよ。 専門の医療機関に行かなくても、手順書さえあれば、誰でも、簡単に、自分一人でできるんだ。 半日でできる。 そして、その効果が、何ヶ月も持続する。 場合によっては、何年も続くかもしれない。 瞑想に比べると、圧倒的に、お手軽だね。瞑想の場合、効果が出るまでに、何週間もかか
社内ドキュメントはなぜ更新されないのか？情報の鮮度を最小限の運用負荷で維持する「イミュータブルドキュメントモデル」のススメ - KAKEHASHI Tech Blog
はじめに こんにちは。カケハシの各プロダクトを支えるプラットフォームシステムの開発チームでテックリードを担当しているkosui(@kosui_me)です。 プロダクト開発の世界では、明瞭な社内向けドキュメントを書くための方法が数多く提案されてきました。読者の中には、製品要求を明瞭にするためにPRD (Product Requirements Document、製品要求仕様書) を書き、プロジェクトの背景から全体の設計やその代案について明瞭にするためにDesign Docsを書き、アーキテクチャに関する意思決定の記録を明瞭にするためにADR(Architecture Decision Record) を書いてきた方も数多くいらっしゃると思います。 しかし、どんな素晴らしいドキュメントも、何故か更新されなくなります。新メンバーへのオンボーディングのためにインフラ構成図を検索したあなたが見つけた
誰も教えてくれないSIの本質、SIerの世界観
本記事について 国内の IT 業界について、ネット上では「SIer」VS「Web系」の構図がしばしば見られる。本記事は前者、SIer の世界観をひとりの当事者として雑多にまとめたものである。記事としては読み物、特にポエムの類。 対象読者 以下を想定する。 ITエンジニアまたはその卵で、 SIerを知らないWeb系の人 SIerに入社した新人や中途入職者 SIerにてSEまたはマネージャーして働いている者 SIerにてSEではないが裏方で働いている者（開発、研究、調査、教育、管理など） 学習や就労の初歩として参考にしてもいいし、議論やキャリアのダシに使っても良いだろう。 筆者について 吉良野すた: https://stakiran.github.io/stakiran/ 国内の大手 SIer に勤めるサラリーマン。現場には出ておらず、裏方で支えてメシを食べている。SI にも IT にもさほど
2. 自己紹介 湖山 翔平 / @sion_cojp 元FPSプロゲーマーでアジアチャンピオン qiitaをよく書いてます (http://qiita.com/sion_cojp) インフラエンジニアとしてよく使うコマンド集 インフラエンジニア 株式会社リブセンス
追記（19日）東洋経済オンラインの的外れ記事 / 高木浩光＠自宅の日記 - 治外法権のeLTAX、マルウェア幇助を繰り返す無能業者は責任追及されて廃業に追い込まれよ
■ 治外法権のeLTAX、マルウェア幇助を繰り返す無能業者は責任追及されて廃業に追い込まれよ ここ数年、不正送金の被害がインターネットバンキングの法人口座で急増しているという*1。その原因は今更言うまでもなく、Java実行環境（JRE）やAdobe製品の古いバージョンの脆弱性を突いてくるマルウェアである。しかしそれにしても、法人口座を扱うパソコンがなぜ、Java実行環境やAdobe製品をインストールしているのだろうか。インストールしなければ被害も起きないのに……。 その謎を解く鍵が、eLTAX（地方税ポータルシステム）にあるようだ。eLTAXでは、インターネットバンキングの口座を用いた納税ができることから、インターネットバンキング用のパソコンでeLTAXの利用環境も整えるということが普通になっていると思われる。そのeLTAXが、昨日までは、Java実行環境のインストールを強要していた。eL
私は、昨年度、工業標準化事業に対する貢献により経済産業大臣から表彰を受けました。編集委員会から私に与えられたテーマは、それについて解説せよというものです。しかし、その技術的な内容については既に本ニュースの2004年6月号において「宇宙開発における標準化と情報化」という題名で執筆しています。そこで、今回は、私が標準規格などの文書の作成に力を入れている理由についてお話ししたいと思います。なぜならば、その理由をお話しすることは、「人工衛星のような複雑なシステムをいかに効率的に開発するか」という私のシステム工学的な研究の成果を解説することになるからです。 人工衛星のような複雑なシステムの開発は、必然的に大人数のチームで行うことになるのですが、効率的に開発を行うための一つの原則は、「チーム構成員の誰もが何かしら具体的な作業を担当し、その作業結果を文書などにまとめ、プロジェクトの中で機能させること」だ
生まれてはじめて書く人のための、小学生向け小説執筆マニュアル（手順書） 読書猿Classic: between / beyond readers はオールインワンの総論だったので、各論をもう少し詳しく説明しろ、という話がありました。 今回は、小説だけでなくマンガでも映画でも共通するストーリーをつくることに焦点をあわせて、なるべくわかりやすく説明してみます。 ストーリーは最低３つのパートからできている 当たり前のことからはじめましょう。 世界最初の創作論（『詩学』）を書いたアリストテレスは、ストーリーは〈はじめ〉〈なか〉〈おわり〉の３つでできているといいました。 というのも、ストーリーは、 ・始まったら必ず終わらなくてはならない→〈はじめ〉から〈おわり〉へ ・しかしいくらか続かなくてはならない→ある程度の長さがある＝〈なか〉が必要 からです。 ストーリーには変化（落差）が必要 ストーリーには
2024年1月時点のAWSベストプラクティスに従って作成しました 好評でしたら続編も検討します 1. 環境ごとにアカウントを分離する 本番、検証、開発ごとにアカウントを分割しましょう ✕良くない例 ◎良い例 最初にアカウント分割しておかないと、後で分割するのはとても大変です アカウントを分割することで「検証と思って作業したら、実は本番だった」のような事故を減らすことができます コストがアカウント単位で集計されるため、環境ごとのコストを簡単に算出することができます AWS Organizationsを使用することで、各環境に応じた権限設定が簡単にでき、ガバナンスを強化することができます AWSアカウントはAWS Control TowerのAccount Factoryを使用することで、クレジットカード情報を都度入力することなく簡単にアカウントの払い出しが可能です また、AWS Contro
今の場合は A さんが 31 歳の場合のストーリーでしたが、A さんが 20 歳～ 35 歳のうちのどの年齢であったとしても、似たようなストーリーで必ず 4 回の質問で当てることができます！(他の例も是非考えてみてください。) ちなみに、このような「真ん中で切ってどちらかに絞って行く」タイプのアルゴリズムには二分探索法という名前がついています。応用情報技術者試験でも頻出のテーマですので馴染みのある方も多いと思います。 1-2. つまり、アルゴリズムとは 上の年齢当てゲームという問題では、相手の年齢を当てる「方法・手順」を二分探索法に基づいて導きました。このようにアルゴリズムとは、 問題を解くための方法・手順 のことです。さて、アルゴリズムと聞くと「コンピュータ上で実装されたプログラム」のことを思い浮かべる方も多いと思いますが、必ずしもコンピュータと関係がある必要はなく、日常生活でも多々登場
2013年04月02日 iPhoneの神アプリを列挙するスレ Tweet 26コメント ｜2013年04月02日 20:00｜スマートフォン・ガジェット｜Editタグ ：iosiPhoneアプリ ※スレッド投稿ありがとうございます！ スレタイ「神アプリを列挙するスレ★46」 3 ：iPhone774G：13/02/12 16:44 ID:UrVBhrnh0 前スレより（リジェクト含） 【2ch】twinkle 、GraffitiPot、BB2C 【天気予報】Yahoo!天気 【RSSクライアント】Reeder2.54、Sylfeed、Newsify 【ブラウザ】iCab Mobile、Sleipnir、Libing 【ウェブクリップ】Pocket、Offline Pages、EverClip、QuickEverClip 【ファイラー】GoodReader、iFiles 【クラウド/ストレー
前回の記事 生まれてはじめて書く人のための、小学生向け小説執筆マニュアル（手順書） 読書猿Classic: between / beyond readers について、物語の作り方はわかった気がするけど、それをいざ小説にしようとすると言葉が出てこない、なんとかしろ、という意見がありました。 実は、小説の文章についても少し書いていたのですが、あまりにも小学生向けでなかったので省きました。参考になる人がいるかもしれないので出してみます。 １ 小説の文章は何からできているか？ 小説は、文章を通して物語を伝えるものです。 小説の文章は、大きく３つに分けられます。 《場面》、《説明》、《描写》です。 （１）説明とは 《説明》は、物語を大づかみに述べる文章です。細かいところを省略して伝えるので《要約》と呼ばれることもあります。 大づかみなので、少しの文章で、長い時間の物語を伝えることができます。 わず
2016.06.06｜最終更新：2017.11.17 ITインフラって面白い！一般人でも分かるインフラの入門スライド10選 ITのインフラエンジニアと言われてどんな仕事か想像がつきますか？ 一般人ではインフラと言われれば水道や橋なんかをイメージするくらいで、ITインフラが何かと聞かれてもよく分からないものです。 そこで、今回は社会を支えるITインフラの基礎が分かるスライドを10個ご紹介します！ インフラエンジニアの定義、基礎、手順書の書き方、自動化など、インフラ初心者から中級者くらいまでを対象にしたスライドです。 これからはじめるインフラエンジニア スライド ⇒ これからはじめるインフラエンジニア 広告やゲーム、メディア事業を展開する株式会社ドリコムによるスライドです。 ITインフラで用いられるOS、ミドルウェア、ソフトウェア、ネットワーク、ハーデウェアなどについて理解しやすくまとめられて
みずほ銀行：システム障害に関するお知らせおよびお問い合わせ先 http://www.mizuhobank.co.jp/oshirase.html 中段の「システム障害特別調査委員会の調査報告書について」のリンク 直リンクはこれ（5/20掲載） 前半しばらく「グダグダ鬱陶しい能書き」が続きますが9ページ目の「3. 本障害発生以前のシステム障害及び対応状況」あたりからギアが入って、11ページ目の「4. 本障害の発生事実」からトップギアというかちょっとしたヘル絵図であります。 ……ああ、その前にここを引用しておこうかな、4-5ページの「2. システムの概況」内「(3) 次期システムの概要」箇所。 (3) 次期システムの概要 次期システムについて、ビジネス環境の急激な変化に対応すべく、肥大化・複雑化した現行システムを新たなシステムとして再構築するために、2004 年から MHFG を中心に検討
首相官邸の公式ホームページが2012年4月2日、リニューアルされた。 これが「お金をかけすぎている」とインターネット上で批判の嵐となっている。増税や公務員削減などが実施されようとしている中、無駄使いではないかという声が多くあがっているのだ。 首相官邸HP、リニューアルに4500万円 ネットで怒りの声 「もっと安くできる」 – J-CASTニュース この記事ですが、ネット上での「高い」という声は一般消費者感覚としては理解出来ますが、Web業界で働く私の周囲のリアルな同業者からも、ネット上の一般の方と同じように「高い」「騙されてる」「金のムダ使い」というような意見が出まして、ちょっと違和感を覚えました。 また一方で、同業の方でも実際このクラスの規模の案件を受託しているような受託業者さん界隈からは「これくらいはかかる」「この金額以下だと受けられない」という声も聞かれました。 私は後者の声に同感で
今日、小保方晴子が事件後はじめて記者会見をした。午後１時からの記者会見は、他の番組を取り止めて、全局で中継され、異様なほどの注目を浴びた。記者会見はニコニコ生放送でも配信され、累計55万人以上が視聴するなど、こちらも記録的な視聴者数となった。 涙で言葉詰まらせ「それでも、STAP現象は真実です」、産経ニュース、2014年4月9日 この分野に明るい専門家たちの意見では、今回の２時間半に及ぶ会見ではひとつも新しい情報がなかったようだ。ただ涙を流しながら、「STAP細胞はできたんです。信じて下さい」と訴え、「捏造ではありません」と連呼した。しかし、具体的な証拠となると、「ノートは機密研究なので見せられない」「再現実験に成功した第三者の名前は明かせない」「具体的なレシピは将来の研究で明らかにする」などと言って巧妙に逃げてしまう。これら全てに、すでに多くの識者が反論する記事を書いているので、ここで僕
｢手順書｣のススメ - Masteries
こんにちは, id:papix です. この記事は, ｢はてなエンジニア Advent Calendar 2018｣の9日目の記事です. qiita.com 昨日は id:wtatsuru さんによる, ｢基盤開発観点からみたはてなのAWS活用のこれまでとこれから｣でした. wtatsuru.hatenadiary.com ｢手順書｣のススメ さて, 早速本題に入っていきましょう. 皆さんは｢手順書｣を書いていますか? 自分はと言うと, 最近そこそこの規模のオペレーションが必要なタスクを担当する機会が多く, その度に手順書を書いて, レビューしてもらってからオペレーションをするようにしています. 例えば, 今年実施した｢はてなが提供するドメインを利用したブログのHTTPS化対応｣のリリースの時は, このような手順書を書いていました: この時は, GitHubのIssueに手順書を用意してい
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Windows7 搭載マシンを買ってきてやったことまとめ - IT戦記
質の高い技術文書を書く方法 - As a Futurist...
見積・提案書に書いておくと不幸を減らせる前提条件
2010年度版・とても参考になった国内のWeb制作関連エントリーまとめ - かちびと.net
「何を言っているのか分からない」と言われないための「伝え方」のノウハウ - Qiita
インフラエンジニア以外も必見！インフラの基礎が学べるスライド10選-レバテック
生まれてはじめて書く人のための、小学生向け小説執筆マニュアル（手順書）
プロジェクトの残業を50%削減したタスク管理手法を惜しみなく公開する - Qiita
GoFの23のデザインパターンを，Javaで活用するための一覧表 （パターンごとの要約コメント付き） - 主に言語とシステム開発に関して
エンジニアはどのようにして技術を学べば良いのか
日本の行政機関等が公開しているAPIについてのまとめ（2016年8月17日暫定版。随時更新） - Qiita
全社的に会社用GitHubアカウントを廃止した件 - ZOZO TECH BLOG
【社内資料公開】運用手順書を作る時のポイントについて書いてみた | DevelopersIO
KDDIの通信障害についてまとめてみた - piyolog
手軽に負荷テストができるツール「Taurus」がスゴい
マンションの大規模修繕で取り回しやってたら、何故かslackで業者さんの業務改善までやることになってたでござるの巻
職場の発達障害者に潰される｜あんきも｜note
書評「入門 監視」雰囲気で監視をやっているすべての人にオススメ | DevelopersIO
インフラエンジニアの綺麗で優しい手順書の書き方
技術者よ、設計しよう、仕様書を書こう | 宇宙科学研究所
これはストーリーをつくるのが苦手な人のために書いた文章です
業務でAWSを利用する時に知っておくべきポイント10選 - Qiita
アルゴリズムとは何か！？ ～ 文系理系問わず楽しめる精選 6 問 ～ - Qiita
iPhoneの神アプリを列挙するスレ : ライフハックちゃんねる弐式
物語は作れたがどんな文章で小説にしていいか分からない人のための覚書
ITインフラって面白い！一般人でも分かるインフラの入門スライド10選 - Findy
みずほ銀行の3月のシステム障害の調査報告pdfが超面白いのでマはみんな読むべき « おれせん。
首相官邸ホームページのリニューアル構築費用に対して製作者側からの考察
謎はすべて解けた!! それでも、STAP細胞は捏造です : 金融日記