ommunibus-gitlabのバージョンを6から10まであげた - Qiita
以前、手動インストールしたDBがmysqlなgitlabをOSとDBもろとも移行コンバートバージョンアップしたときよりはだいぶ簡単で使ってる人も小数社内なので気が楽でしたが、 結構段階ふまないといけなかったりエラー出たり変わったところがあったようなので備忘録しておきます。 概要 移行元： CentOS6 以下が入ってた（rpmは大事に取っておいてあった） gitlab-6.8.2_omnibus-1.el6.x86_64.rpm 移行先： CentOS7 最終的には以下にしたい gitlab-ce-10.0.3-ce.0.el7.x86_64.rpm 参考 基本的にはgitlab本家のommunibus用バージョンアップマニュアルを見て作業。 遭遇したエラー 7.2.0から10.0へ上げたらpostgresqlのスクリプト実行に失敗とのエラー。切り戻し時にredisが起動しなくなるエラーも
エンジニア歴20数年の私が、設計書を書く際に心がけていること - Qiita
はじめに 時の経つのは早いもので、私がIT業界に身を置いて四半世紀になってしまいました。 その間、膨大な数の「設計書（仕様書）」を書いて来ましたが、未だに悩み・迷いは尽きません。 それでも、亀の甲より年の劫とも申しますので、私なりの経験則を「個人」と「チーム」の両観点でまとめてみました。 本稿のテーマは、「主に設計書を想定した、開発ドキュメントの書き方」です。 本稿で前提とする設計書は、ExcelやWordで書かれた、フォーマルな（≒納品物になりえる）設計文書、です。 したがって、自社サービス開発よりも受託開発、アジャイルよりもウォーターフォール、を前提として読んでいただいた方が、しっくりくると思われます。 ＜ご注意＞ 本稿の内容は執筆者独自の見解であり、所属企業における立場、戦略、意見を代表するものではありません。 個人的に心がけていること 当該文書の作成目的や位置付けを冒頭に記載する
SSL/TLSについてまとめ2018 - Qiita
はじめに SSL/TLSについて改めて理解を深めたい思い、関連する技術についてまとめました。 本記事はTLSに関すること主題として、HTTPS、暗号化、Apache、OpenSSL等について記載しています。 SSL/TLSの通信は色々なプロトコルや暗号化方式が組み合わされ補いあってできています。暗号化の仕組みはパズルのようで面白いです。一つ一つを読み取り理解が深まるごとで、SSL/TLSって本当によくできると思いました。フレームワークの意味について考えさられます。 HTTPSの通信 HTTPSの通信はTCP/IPプロトコルスイートとして、TCPの上層にSSL/TLSがあり、アプリケーションプロトコルのHTTPプロトコルが載って通信をしています。 コネクションとセッションは通信の概念として別になります。TCPでクライアントからWebサーバに対してコネクション(経路)が確立され、その上でセッシ
PostgreSQLのbackup, restore方法まとめ - Qiita
(1) PostgreSQLのダンプツールを利用したバックアップ pg_dumpコマンド DBを運用しながらでも使えるbackupコマンド 中ではトランザクションブロック内でSELECT文を発行し、取得したデータを出力形式に合わせて整形した腕標準出力に出力 するらしい。 pg_dumpの出力形式 スクリプト形式(デフォルト) アーカイブ形式 が選択できる。 スクリプト形式 スクリプト形式の出力は、リストアに必要なSQL文の羅列が出る。 ので、psqlコマンドでリストアする。 スクリプト形式の場合はプレーンテキストなので、リストアの際にエラーが出たら、中を見れるという利点がある。 アーカイブ形式 バイナリの形で出力される。リストアはpsqlコマンドでなくpg_restoreコマンドで行う。 アーカイブ形式の利点は、 ｢指定したtableのみを選択してリストアできる｣ことらしい。 また、アーカ
ガチ素人が1ヶ月でディープラーニングのジェネラリストになった話 - Qiita
はじめに なんか、ガチ素人って書くとAVみたいですね ディープラーニングの知識ゼロの素人でしたが、1ヶ月の勉強でディープラーニング ジェネラリスト試験1に合格しました。 せっかくなので、自分の経験を踏まえつつ合格への（おそらく）最短ルートをまとめてみます。 これからチャレンジしてみようという方の参考になれば幸いです。 ちなみに、僕のスペックはこんな感じです。 数年前まで理系の大学院生だった。 専攻は機械工学だったので、ディープラーニングの知識はゼロ。行列の計算くらいはできる。 お仕事は上流という名のパワポ職人。 多分これが一番早いと思います Coursera 色々なところで紹介されているので、今更細かい解説はしません。 騙されたと思って、Andrew先生の機械学習講座を修了してください。 修了する頃には「何がわからないかがわかる」＝「次にどんな勉強をすれば良いかわかる」ようになっていると思
タイムゾーン呪いの書 - Qiita
コメント欄で「Software Design 誌 (2018/12) に寄稿した内容や修正などをこちらの記事にも適用したい」と言ったあと、やるやる詐欺でずっと放置していましたが、三年近く経ってようやく 2021年 7月に大幅に改訂し、同時に Zenn に引っ越すことにしました。 タイムゾーン呪いの書 (知識編) タイムゾーン呪いの書 (実装編) タイムゾーン呪いの書 (Java 編) なにやら長くなりすぎたので三部構成になっています。 この Qiita 版は、しばらく (最低一年は) 改訂前のまま残しておきます。 タイムゾーンの存在はほぼ全ての人が知っていると思います。ソフトウェア・エンジニアなら多くの方が、自分の得意な言語で、タイムゾーンが関わるなにかしらのコードを書いたことがあるでしょう。ですが、日本に住んで日本の仕事をしていると国内時差もなく1 夏時間もない2 日本標準時 (Japa
Ethereumの学習フローを整理した - Qiita
ブロックチェーンの勉強を始めて、そろそろ1年です。 最初はBitcoinを動かしてみたり、API使って、簡単な送金アプリを作ってみたりしました。 去年の春から夏にかけては業務の関係でFabricを中心にHyperledgerプロジェクトのブロックチェーンを触っていました。 しかし、Fabricだけ分かっててもな〜と思い、9月からEthereumの勉強を始めました。 これが運の尽きでした... 「...Ethereum、めっちゃ楽しいじゃん！！！！」 Ethereumにどっぷりとハマってしまいました。学習しても、しても終わりが見えない感じが楽しいですね（笑） 学習を始めてからもう少しで半年、一通りEthereum周辺の技術を触ったので、備忘の意味を込めて、学習の流れを整理してみました。 なお、今後も新しい技術を触ったら、随時更新していく予定です。 他にも、これやった方がいいよというものがあれ
【今日からできる】コミットメッセージに 「プレフィックス」 をつけるだけで、開発効率が上がった話 - Qiita
はじめに 今まで commit message を「なんとなく」書いていたが、プレフィックスをつけることで、コミットメッセージに対する考え方が変わった。 そのおかげで開発効率が上がったので、その内容をシェア。 プレフィックスをつけるってどういうこと？ 以下のようにコミットメッセージの先頭に、なんらかの文字をつけること。 feat: xxx という機能を追加 fix: yyy で発生するバグを修正 refactor: zzz の機能をリファクタ のように feat, fix, refactor などがプレフィックスです。 最近 OSS の Contribution Guide などでよく見かけます。 導入したプレフィックスルール Angular.js/DEVELOPERS.md Angular.js の開発者ガイドに書いてあるメッセージを参考にしました。 以前のコミットメッセージ（例 ちなみ
Git LFS で大きいサイズのバイナリファイルも Git で管理する 🚀 - Qiita
Git LFS （Git Large File Storage） とは、Git で大きいサイズのバイナリファイル（本稿では、ラージファイルと省略して呼びます）をバージョン管理するための仕組みです。 Git はその性質から、ラージファイルを扱うにはいくつかの問題をはらんでいて、Git LFS はその問題を解決するための機能を Git の拡張として提供するものです。 本稿では Git LFS の概要紹介として、どういった問題が存在していて、どのように解決されるか、一方でどういった問題が解決されないかまでを、まとめて紹介します。 Git のラージファイル管理における問題点 まず Git LFS の背景として、ラージファイル管理における問題点を、Git の特徴を抑えつつ紹介します。 バイナリファイルの管理に不向き Git は、ソースコード（テキストファイル）のバージョン管理に特化したツールです。
コンピュータ業界でよく出る英語 - Qiita
みなさまへのお願いごと 間違いなどの指摘は、編集リクエストでお願いします。 コメントの記載はページが長いこともあり、お控えください。 TOEIC900でも英語が話せない日本人へ ITエンジニアの私がなぜ令和の今、中国語を学ぶのか？ 名詞/イディオム gotcha はまりポイント。注意すべきこと。引っ掛け。 Got you のくだけた表現。捕まえた、誰かをトラップに引っ掛ける、という意味から。 注) 一般的には、Got itやYup、I seeのような、同意の返事でよく使われる。 類) caveat, pitfall There are many gotchas in this application. sought-after (スキル、人材、機能、アプリが) 人気の、需要がある、求められてる、引っ張りだこ Python is a sought-after language. c-suit
誤って解放したElastic IP(EIP)を復旧する - Qiita
オペミスでElastic IPアドレス(EIP)を解放できないように、IAMポリシーでElastic IP(EIP)の解放を許可しないという記事を以前書いたけど、復旧するコマンドがあったので、まとめておく。 Elastic IPアドレスの復旧ルール 以下のルールに沿えば、Elastic IPアドレスを解放した場合でも、復旧できる可能性がある。 もともと EC2-VPC で使用するために割り当てられていたか、EC2-Classic から EC2-VPC に移動された Elastic IPアドレスだけを復旧できる。 他のAWSアカウントに割り当てられている場合は復旧できない。 Elastic IPアドレスの割当上限（AWSアカウント作成時のデフォルトでは5個）を超過する場合は、復旧できない。 ユーザーガイド(日本語版)では、以下のように記述されているが誤訳。 もともと EC2-VPC で使用す
3大クラウドのCPU脆弱性(Meltdown/Spectre)対応状況メモ - Qiita
1/11 Amazon Web Services ブログに下記の日本語訳版が投稿されました。 プロセッサの投機的実行に関する公開調査について https://aws.amazon.com/jp/blogs/news/processor_speculative_execution_research_disclosure/ Processor Speculative Execution Research Disclosure https://aws.amazon.com/jp/security/security-bulletins/AWS-2018-013/ すでに脆弱性から保護された状態にある。 圧倒的多数のEC2で有意義なパフォーマンスへの影響も見られなかったとしている。 ただし、保護強化のため仮想マシンOSレベルでも顧客自身でパッチを適用することを推奨している。 Amazon Linux
「AWS、またパッチ当てたってよ」と聞いたので3度目のAurora（MySQL互換）R4テスト（mysqlslap） - Qiita
「AWS、またパッチ当てたってよ」と聞いたので3度目のAurora（MySQL互換）R4テスト（mysqlslap）MySQLAWSAurora タイトル通り、です。 ※パッチを当てたのか別のことをしたのかは、自分ではまだ情報を捕捉できていません。そのため、今後情報を追記する可能性があります。 結果、「元の性能に戻ったみたい」です。 ※以下の記事の続報です。 MeltdownとかSpectreとか騒ぎがあったので、Amazon Aurora（MySQL互換）R4インスタンス再テスト（mysqlslap） 2018/01/15追記（01/16一部修正）： AWSとしては「対応を完了した」という認識のようですが、詳細な情報は出していません。 Processor Speculative Execution Research Disclosure ※2018/01/13 13:00 PST 更新版
San Francisco フォントを探る - Qiita
San Francisco Font Family San Francisco はひとつの書体ではなく、SF Pro, SF Compact などと呼ばれ、それぞれに Text, Display, Rounded バージョンが存在します。Text よりも Display の方が多くのウェイトを揃えているのは、Text は視認性を重視した書体ゆえ、細いものは利用する想定にないからなのだと思われます。SFシリーズはVariable fontに対応しています。 SF Pro vs. SF Compact SF Pro は macOS や iOS, tvOS デバイスのシステムフォントとして採用されています。SF Compact は Apple Watch のシステムフォントとして採用されています。Compact は字が四角形に近い形をしていて、Apple Watch のような小さなデバイスでも視
LinuxコアメンバーによるMeltdownとSpectre 対応状況の説明 （1/19更新） - Qiita
はじめに Linuxの安定カーネルのとりまとめ役、グレッグ・クラーハートマンによるメルトダウンとスペクター問題に関する1/6時点での現況の説明の訳文です。 太字は訳者が主観で独自に付加したものです。 2018/1/19: 対応状況がGreg氏によりアップデートされましたので、追記しました。 ライセンス 原文は当人のブログでby-nc-sa3.0で公開されています。 この文章のライセンスも原文に準じます。 謝辞 何よりもまず多忙な中情報をシェアしてくれた原著者のGreg氏に。 表記間違いについて指摘ありがとうございます。以下修正しました。 https://twitter.com/KuniSuzaki/status/950888858568163328 ライセンスの表記間違いを修正しました。ご指摘ありがとうございました。 @7of9 さんより明らかな誤認・誤訳・見落とし箇所への編集リクエストを
MeltdownとかSpectreとか騒ぎがあったので、Amazon Aurora（MySQL互換）R4インスタンス再テスト（mysqlslap） - Qiita
MeltdownとかSpectreとか騒ぎがあったので、Amazon Aurora（MySQL互換）R4インスタンス再テスト（mysqlslap）MySQLAWSAurora 2018/01/13追記： 「AWSが再度パッチを当てたみたい」という情報があったので、3度目のベンチマークを行ったところ、db.r4.largeおよびdb.r4.xlargeについて、2017/10/末頃とほぼ同じ速度に戻ったことを確認しました。 「AWS、またパッチ当てたってよ」と聞いたので3度目のAurora（MySQL互換）R4テスト（mysqlslap） （以下、古い情報なので現在とは状況が異なります。） 以前、R4インスタンスが使えるようになったときにmysqlslapで性能テストをしたので、今回、同じ条件で再度R4インスタンスだけmysqlslapしてみました。 Amazon AuroraでR4インスタ
CPU脆弱性Meltdownのパッチ適用でベンチマークスコアが25％低下した - Qiita
いま話題のCPU脆弱性Meltdownですが、 各OSベンダーからカーネルのパッチが配布され始めました。 個人で利用しているEC2にパッチを適用して、ベンチマークをとったところ、 トータルスコアが25％低下という結果が出ましたのでまとめます。 ※環境やCPUの種類やベンチマークの取り方で変わるので、 必ずしも全ての環境においてこの結果が正しいわけではありません。 環境とスペック EC2インスタンスタイプ：t2.midium OS： 3.10.0-693.11.6.el7.x86_64 (CentOS 7) CPU： Intel(R) Xeon(R) CPU E5-2676 v3 @ 2.40GHz (2コア) 結論 コンテキストスイッチの速度が低下する。 Meltdown関連の記事にもあるように、 パッチ適用によってカーネルモードとユーザモードのアドレス空間を分離する措置が取られるため、
net.ipv4.tcp_tw_recycle は廃止されました ― その危険性を理解する - Qiita
Disclaimer 私はネットワークの勉強もちゃんとしたことないし、Linux のソース読むのもはじめてな素人です。 何かおかしなところなどあれば、遠慮なくコメント欄でまさかりをお願いいたします。 ソースコードの引用に関して 本文中で Linux のコード／ドキュメントを引用している箇所がありますが、すべてタグ v4.11 のものです。また、日本語のコメント・翻訳文は筆者が入れたものです。 TL; DR Linux のカーネルパラメータ net.ipv4.tcp_tw_recycle は、バージョン4.12から廃止されました。 今後はこの設定は行わないようにしましょう（というかできません）。 一方、net.ipv4.tcp_tw_reuse は安全であり、引き続き利用できます。 …というだけの話なのですが、自分用にメモがてら経緯・背景などを記録しておきます。 なんで気がついたか このパラ
Terraformの使い方 ver.2017冬 - Qiita
続きをかきました→ https://qiita.com/uraura/items/e13d883827443f27bf98 概要 TerraformでAWSのリソース管理をしていますが，(少人数でやるには1)まぁまぁ良い感じに落ちついたのでご紹介します． 以下，話を簡単にするためにTerraformでAWSのリソースを管理しているという前提で話をすすめます． 問題 Terraformは便利で，使いはじめると何でもかんでもコード化してやろう!!などと思ってしまいますが，すぐに以下のような問題にぶち当たります． コード化をすすめるとplan/applyにかかる時間が増大していく planが通ってもapplyでコケる場合がままある コード化をすすめるとplan/applyにかかる時間が増大していく コード化されてるリソースが少ないうちはあまり問題にならないのですが，時がたちコード量が増えてくると
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
最近の私的 Golang 開発環境 - Qiita
