エンジニア歴20数年の私が、設計書を書く際に心がけていること - Qiita
はじめに 時の経つのは早いもので、私がIT業界に身を置いて四半世紀になってしまいました。 その間、膨大な数の「設計書（仕様書）」を書いて来ましたが、未だに悩み・迷いは尽きません。 それでも、亀の甲より年の劫とも申しますので、私なりの経験則を「個人」と「チーム」の両観点でまとめてみました。 本稿のテーマは、「主に設計書を想定した、開発ドキュメントの書き方」です。 本稿で前提とする設計書は、ExcelやWordで書かれた、フォーマルな（≒納品物になりえる）設計文書、です。 したがって、自社サービス開発よりも受託開発、アジャイルよりもウォーターフォール、を前提として読んでいただいた方が、しっくりくると思われます。 ＜ご注意＞ 本稿の内容は執筆者独自の見解であり、所属企業における立場、戦略、意見を代表するものではありません。 個人的に心がけていること 当該文書の作成目的や位置付けを冒頭に記載する
コネクションプールのチューニング - Qiita
TL;DR 負荷の変動が激しい環境でコネクションプールの設定のチューニングをさぼるためによくやるハックを紹介します。 問題 Go から https や mysql など外部のリソースにアクセスする場合、一般的にコネクションプールを使うことになります。 コネクションプールは、利用が終わった (idle) コネクションをプールしておき、次に使いたい時に再利用するものです。 (idle コネクションのプールを以後 free pool と呼びます。) ほとんどのコネクションプールの実装には、 idle なコネクションの最大数を制限するオプションがあります。 また、利用中の (active) コネクションと idle なコネクションを合計した全体を制限するオプションを持つものもあります。 例えば net/http パッケージの Transport は MaxIdleConnsPerHost というフ
JSフレームワークの末端がWebComponentsになるのか、なれるのか、検証してみた - Qiita
https://speakerdeck.com/mizchi/real-world-es201x-and-future で、「Reactやその他のフレームワークの末端はWebComponentsになるのではないか？」という話をした。とはいえ、実際に自分でそういうものを実装したわけではなかった。 じゃあ実際に、Reactから web components を呼ぶにはどうなるだろうか？実装してみた。 ゴールの設定 こういうコードが動いてほしいとする。 import React from 'react' export default class Home extends React.Component { constructor() { super() this.state = { value: 0 } } componentDidMount() { let cnt = 0 setInterva
“Web Componentsだけ” で新サービスを実装して見えたこと - Qiita
Double O というサービスを作りました。 フロントエンドはピュアな Web Components を採用していて、バックエンドは Lambda と DynamoDB のみで構成しました。 (厳密には CloudFront とか API Gateway とかもあるけどそこは省いていいよね？) REST API 以外の Util 系の Lambda 関数はすべて AWS Cloud9 で管理することで環境構築も不要な Lambda ができて楽でした。 TL;DR サーバーレスについてはごく普通のことしかしていないので、詳しくは触れないでおきます。 ピュアな Web Components だけでサービスを成立させることができた。 HTMLElement クラスを継承するだけなのでメジャーライブラリは不要になった。 Web Components の Custom Elements は標準仕様
SSL/TLSについてまとめ2018 - Qiita
はじめに SSL/TLSについて改めて理解を深めたい思い、関連する技術についてまとめました。 本記事はTLSに関すること主題として、HTTPS、暗号化、Apache、OpenSSL等について記載しています。 SSL/TLSの通信は色々なプロトコルや暗号化方式が組み合わされ補いあってできています。暗号化の仕組みはパズルのようで面白いです。一つ一つを読み取り理解が深まるごとで、SSL/TLSって本当によくできると思いました。フレームワークの意味について考えさられます。 HTTPSの通信 HTTPSの通信はTCP/IPプロトコルスイートとして、TCPの上層にSSL/TLSがあり、アプリケーションプロトコルのHTTPプロトコルが載って通信をしています。 コネクションとセッションは通信の概念として別になります。TCPでクライアントからWebサーバに対してコネクション(経路)が確立され、その上でセッシ
k-meansの最適なクラスター数を調べる方法 - Qiita
背景 お手軽なクラスタリング手段としてk-meansが有名であるが、以下の様な困ったポイントがある k-means法の問題点の一つは、クラスタの個数kを指定しなければならないことだ。 クラスタリングは探索的 (exploratory) なデータ解析手法であって，分割は必ず何らかの主観や視点に基づいているということです．よって，クラスタリングした結果は，データの要約などの知見を得るために用い，客観的な証拠として用いてはなりません． 参照元 それは知っている。で、結局クラスター数は本当に分析者の決め打ちでいいのか？ 「このクラスター数はどうやって決めたの？」「これまでの分析結果からソーゴー的に考えて決定しました」とか言いたくない このページの目的 「最終的には分析官の判断でクラスターは決定しました」といいつつも、何かしら数値としての根拠を持ってクラスター数を決定したい 何か良い判断基準は無いの
【2018年版】今押さえておきたいフロントエンド関連 - Qiita
個人的に押さえておいたほうがいいと思う情報や最近動向が気になっている情報をまとめました。 短時間調べた程度でザックリ書いてますので、掲載している情報に間違いなどありましたら、 ご指摘いただけると助かります。 現時点でWorking Draft,Editor's Draftの情報もありますし、ブラウザ側でほとんど実装されてないプロパティ（業務ではあまり使えない系）も積極的に載せていっているので、対応状況についてはCan I useやMDNで調べてください。 途中まで載せてたけど多すぎてあきらめた... HTML Resource Hints(dns-prefetch, preconnect, prefetch, prerender) 指定しておくことで、ページ遷移時に名前解決・接続・リソースの取得・レンダリングを早めることができる。 Link types - HTML | MDN Prelo
タイムゾーン呪いの書 - Qiita
コメント欄で「Software Design 誌 (2018/12) に寄稿した内容や修正などをこちらの記事にも適用したい」と言ったあと、やるやる詐欺でずっと放置していましたが、三年近く経ってようやく 2021年 7月に大幅に改訂し、同時に Zenn に引っ越すことにしました。 タイムゾーン呪いの書 (知識編) タイムゾーン呪いの書 (実装編) タイムゾーン呪いの書 (Java 編) なにやら長くなりすぎたので三部構成になっています。 この Qiita 版は、しばらく (最低一年は) 改訂前のまま残しておきます。 タイムゾーンの存在はほぼ全ての人が知っていると思います。ソフトウェア・エンジニアなら多くの方が、自分の得意な言語で、タイムゾーンが関わるなにかしらのコードを書いたことがあるでしょう。ですが、日本に住んで日本の仕事をしていると国内時差もなく1 夏時間もない2 日本標準時 (Japa
エンジニアの次のステップへの勉強法 - Qiita
言われたものはだいたい作れるし、どんなプログラミング言語が来ても大抵書けそうかなってなったエンジニアがそこで成長が止まってしまう人を見かけることがあります。 技術が好きで、作ることが好きで、なのに環境に求められず成長が止まってしまっているんだろうと思います。 ここで成長が止まってしまう環境とは、 新しい技術の情報を仕入れて語り合うエンジニアが居ない 業務用件に高い技術が求められない 改善サイクルが遅い 開発プロセスなどをまとめる人がいない などです。 簡単に言うと、今はうまく仕事があるけれど、停滞している仕事場ですね。 下手にビジネス的に成り立ってしまっているので、それ以上成長をする必要がないのです。 まあ、そういう生き方もありかな？って思うので、それでいいやって思う人は続きは読まなくてもいいかなって思います。 ここから先はエンジニアとして技術を伸ばすことが楽しい、ものを作ることが楽しい、
もう管理画面のフロントコードを書く必要はありません、そう Viron ならね。 - Qiita
管理画面のフロントエンドコードを書く時代は終わりました。 Vironがあれば、OpenApi(Swagger)でAPI定義を行い、実装するだけで管理画面が完成します。 そしてこれはOSSです。誰でも自由にお使いいただけます。 概要 Vironは、複数の管理画面を管理できるよう設計された、管理ツールマネージメントコンソールです。 APIサーバーとOAS2.0 jsonファイルを作成するだけで、管理画面が一つ完成します。 経緯 私の会社では、大小さまざまな自社サービスが開発・運用されています。 管理画面をサービス・サイト毎に作っていましたが、それには限界がありました。 エンジニアからしたら、管理画面用のデザインやAPIを作らなきゃいけない。工数がかかる。 運用・プロデューサーは、UI・UXが管理画面で違うため、操作を覚えるという学習コストが高い。 さらに外から見たいときにスマホから見れないし、
【今日からできる】コミットメッセージに 「プレフィックス」 をつけるだけで、開発効率が上がった話 - Qiita
はじめに 今まで commit message を「なんとなく」書いていたが、プレフィックスをつけることで、コミットメッセージに対する考え方が変わった。 そのおかげで開発効率が上がったので、その内容をシェア。 プレフィックスをつけるってどういうこと？ 以下のようにコミットメッセージの先頭に、なんらかの文字をつけること。 feat: xxx という機能を追加 fix: yyy で発生するバグを修正 refactor: zzz の機能をリファクタ のように feat, fix, refactor などがプレフィックスです。 最近 OSS の Contribution Guide などでよく見かけます。 導入したプレフィックスルール Angular.js/DEVELOPERS.md Angular.js の開発者ガイドに書いてあるメッセージを参考にしました。 以前のコミットメッセージ（例 ちなみ
Electron で Markdownプレゼン作成ツールを作って公開するまで - Qiita
Markdown でスライドを作るためのツールを漁っていたのですが、なかなか自分好みのものが無く、Electron の勉強を兼ねて作ってみた話です。 追記 (2018/12/10): その後の進捗はこちら Puppeteer & Carlo を Markdown スライド作成 CLI ツール (Marp CLI) で活用する - Qiita 成果物 今回作ったプレゼンツールは、以下にてプレリリース版を公開しています。 Marp - Markdown presentation writer https://yhatt.github.io/marp/ (旧称 mdSlide) 追記 (2016/07/13 19:42) ＿人人人人人人人人人人人人人人＿ ＞ 突然のGithubトレンド入り ＜ ￣Y^Y^Y^Y^Y^Y^Y^Y^Y^Y^Y^Y^Y￣ Markdown スライドツール比較表 私の欲
Marp(Markdown Presentaiton)の文法まとめ - Qiita
■ Marpにいて MarkdownでPDF形式のプレゼンテーションファイルを作成できるフリーソフト。 特色は、 日本製 ( 株式会社Speeeの若手エンジニアによる開発 ) 機能がシンプルなので、使いやすい Zipファイルを解凍するだけなので、導入が簡単 ※ 2017-06 「Marp v0.0.10 およびそれ以前」に 脆弱性が発見された模様、最新版へアップデートが必要 https://scan.netsecurity.ne.jp/article/2017/06/29/39903.html ■ スライドの書き方 Markdownで文章を記述↓ # スライドタイトル1 * 例1 * 例2 * 例3 ↓ 次のスライドを作成 ---- # スライドタイトル2 * 例1 * 例2 * 例3
MySQL - ネクストキーロックってどこまでロックされんの？ - Qiita
個人的にMySQL一番の鬼門のネクストキーロック。未だにまともな正解はわからないけれど、法則性らしきものが理解できてきたのでまとめてみる。 そもそもネクストキーロックとは InnoDBの行ロックはネクストキーロックを採用している。検索時はネクストキーロックを用いてインデックス走査を行うので、ギャップロックが起こる場合は常に先のギャップもロックされており、これによってファントムリードを防ぐ。一意のインデックスを持つ固有値検索の場合はギャップロックする必要がないが、値域検索の場合はギャップロックをする。 固有値検索はギャップロックしないはずだが、存在しない行を読み取ろうとした場合は排他・共有ロックではなく、ギャップロックがかかる。同時にネクストキーロックもかかるのでproduct_id = 19にはINSERTできない。 mysql> select * from products where
今さら人に聞けない Kubernetes とは？ - Qiita
Kubernetesを一言で言うと、自動デプロイ、スケーリング、アプリ・コンテナの運用自動化のために設計されたオープンソースのプラットフォームです。 Kubernetesによって、要求に迅速かつ効率良く対応ができます。 アプリを迅速に予定通りにデプロイする (コンテナをサーバー群へ展開する) 稼働中にアプリをスケールする（稼働中にコンテナ数を変更する） 新機能をシームレスに提供開始する (稼働中にロールアウトする) ハードウェアの利用率を要求に制限する (コンテナで共存させて稼働率を高くする） Kubernetesのゴールは、下記の様なアプリの運用負担を軽減するためのエコシステムのコンポーネントとツールを整備することです。 可搬性: パブリック・クラウド、プライベート・クラウド、ハイブリッド・クラウド、マルチ・クラウド 拡張可能: モジュール化、追加可能、接続可能、構成可能 自動修復: 自
ゼロから考える脆弱性対応 - Qiita
はじめに こんなツイートを見かけました。 ・脆弱性ってなんだろう ・脆弱性対応ってなにしたらいいの？ ・情報を集めよう ・該当機器を洗いだそう ・対応方法を決めよう … みたいなまとめほしいけど意外とないから作りたい…作るしかなくない…？ — ナツヨさん@インフラ女子の日常 (@infragirl755) 2018年1月15日 たしかにそうだなぁ。生きてるシステムを運用する現場SEの気持ちになって力試しに書いてみよう。 おことわり 最初に記事スコープのおことわりです。 「 対策 」「 対処 」「 対応 」、似たような言葉ですがこれらを並べて考えたことはあるでしょうか？ 記事名には「 脆弱性対応 」という言葉を使っていますが、「対応」ということでこの記事のスコープを少し狭く取っています。 対策 ・ 対処 ・ 対応の違い 対策: 何かが起きる前に講じる処置や手段のこと。 対処: 何かが起こって
Web Developer Roadmap 2018が出たので2017年版と比較してみる - Qiita
のようなイメージではないでしょうか？ (灰色と橙色の分け方は作者のおすすめ度（匙加減）な気もしなくないんですが） はい…まさにこの通りですのでこれを参照頂ければなと思います。隅まで目を通していないのがバレますね。 では早速本題 🚀Introduction これが2017版 2018版 左の奴らが軒並みチョーヤバいです。雑だな！ まあここは導入みたいなもんなんで深くは追及しません。最早OSSや仮想鯖、クラウド環境化での開発は必須なんだってことが言いたいんだと思います。（適当） デザインパターンってのはGoF(Gang of Four)というおじさん４人がソフトウェア開発に取り入れたオブジェクト指向プログラミングにおけるこう書くとオブジェクト指向的にええと思う！っていうパターンの集まりです。全23種、知らず知らずのうちに使っているものも多いです。 なんで今追加されたのか僕にはよくわかりません
お前らのSSH Keysの作り方は間違っている - Qiita
GitHubのHelpに記述されているSSH Keysの作成方法が僕の知っている作成方法と 微妙に異なっていたので、書いてみました。 以下の参考にしています。 Generating SSH keys - User Documentation SSH Keysの確認 既存のSSH Keysの確認をする必要があるので、以下を実行 デフォルトでのSSH Keysの名前は以下のうちのどれか id_dsa.pub id_ecdsa.pub id_ed25519.pub id_rsa.pub 現在使用している鍵の暗号強度の確認 以下のコマンドにて鍵長が2048以上かつ暗号化方式がRSA、或いはECDSAやEd25519であればOK $ ssh-keygen -l -f ~/.ssh/id_rsa.pub 4096 SHA256:xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
[AWS] 停止したRDSインスタンスが自動で起動していた(注意：EC2と違って7日後に自動で起動されます) - Qiita![[AWS] 停止したRDSインスタンスが自動で起動していた(注意：EC2と違って7日後に自動で起動されます) - Qiita](https://cdn-ak-scissors.b.st-hatena.com/image/square/78a12e5849127300d40962f1c407640bc19d3f27/height=288;version=1;width=512/https%3A%2F%2Fqiita-user-contents.imgix.net%2Fhttps%253A%252F%252Fcdn.qiita.com%252Fassets%252Fpublic%252Farticle-ogp-background-412672c5f0600ab9a64263b751f1bc81.png%3Fixlib%3Drb-4.0.0%26w%3D1200%26mark64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTk3MiZoPTM3OCZ0eHQ9JTVCQVdTJTVEJTIwJUU1JTgxJTlDJUU2JUFEJUEyJUUzJTgxJTk3JUUzJTgxJTlGUkRTJUUzJTgyJUE0JUUzJTgzJUIzJUUzJTgyJUI5JUUzJTgyJUJGJUUzJTgzJUIzJUUzJTgyJUI5JUUzJTgxJThDJUU4JTg3JUFBJUU1JThCJTk1JUUzJTgxJUE3JUU4JUI1JUI3JUU1JThCJTk1JUUzJTgxJTk3JUUzJTgxJUE2JUUzJTgxJTg0JUUzJTgxJTlGJTI4JUU2JUIzJUE4JUU2JTg0JThGJUVGJUJDJTlBRUMyJUUzJTgxJUE4JUU5JTgxJTk1JUUzJTgxJUEzJUUzJTgxJUE2NyVFNiU5NyVBNSVFNSVCRSU4QyVFMyU4MSVBQiVFOCU4NyVBQSVFNSU4QiU5NSVFMyU4MSVBNyVFOCVCNSVCNyVFNSU4QiU5NSVFMyU4MSU5NSVFMyU4MiU4QyVFMyU4MSVCRSVFMyU4MSU5OSUyOSZ0eHQtYWxpZ249bGVmdCUyQ3RvcCZ0eHQtY29sb3I9JTIzMjEyMTIxJnR4dC1mb250PUhpcmFnaW5vJTIwU2FucyUyMFc2JnR4dC1zaXplPTU2JnM9NThjNGJlMDE2ZGZjYTJjNWU4NzA0MDJjOTc5YWRmNDI%26mark-x%3D142%26mark-y%3D57%26blend64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZoPTc2Jnc9NzcwJnR4dD0lNDBWQV9uYWthdHN1JnR4dC1jb2xvcj0lMjMyMTIxMjEmdHh0LWZvbnQ9SGlyYWdpbm8lMjBTYW5zJTIwVzYmdHh0LXNpemU9MzYmdHh0LWFsaWduPWxlZnQlMkN0b3Amcz1lNWFiOWY2N2IyOTNmNzlmMjZkNjIzMTI2ZDc2MzRmOA%26blend-x%3D142%26blend-y%3D486%26blend-mode%3Dnormal%26s%3D427a339612ea84f97560d5366cd68071)
gitでリモートのブランチにローカルを強制一致させたい時 - Qiita
