新しいマシンやスマフォで Slack の各種チームに入るのが面倒くさい！！！という時 - Qiita
新しいマシンやスマフォで Slack App で各種チーム(たくさんある)にログインがすこぶる面倒くさい･･･面倒くさい･･･面倒くさい･･･。という経験したことありませんか。私は4回ぐらいあります。1password 使ってるからパスワードもバラバラだしね･･･。 そんなときは https://slack.com/signin/find のページから Find Another Team を押して自分のメールアドレスを入力すると、そのアカウントに紐付いてるすべての Team アカウントにログインできるマジックリンクがメールで送られてくる･･･！ あとは各種メーラーで、そのリンクをクリックしていくと、Slack app が立ち上がり自動でそのチームにログインできます。PCでもスマフォでも使えるし、うおー便利、マジックリンクが出来た当初から知っておきたかった･･･！！ Register as
不安とストレスから解放される見積りとスケジュール方法 - Qiita
エンジニア組織を強くするための本を出版しました Qiitaでエンジニアリングをめぐる様々なコミュニケーションの問題とその解決策や考え方を書いてきた。それらの背後にあるエッセンスをこの度書籍として出版するに至りました。 エンジニアリング組織論への招待 ～不確実性に向き合う思考と組織のリファクタリング この書籍は、エンジニアリングを「不確実性を削減する」という第一原理で捉え直し、様々なエンジニアリングとその間のコミュニケーションをめぐる現象を説明していくものです。 はじめに 何かはじめてのことをする場合、人はとても「不安」を感じます。人は未来を考えることができる生き物です。その特異な能力ゆえに、未来に起こるかもしれないよくないことを考えると「不安」を感じてしまうのです。 仕事のプロジェクトなどは、「間に合わなかったらどうしよう」とか「この仕事はちゃんと終えられるのだろうか。」など、未来のことを
例外、エラー、異常、そして - Qiita
「例外」「エラー」「異常」あたりの言葉が、言語仕様や設計の中で人によって微妙にずれた使い方されてるから、 「Expected だが Accept されないケース」を表す別の言葉が欲しい。 — Jxck (@Jxck_) 2016年8月31日 @Jxck_ 本来こう分類されて、 1. Expected/Accepted 2. Expected/UnAccepted 3. UnExpected 2, 3 をどう呼ぶかあたりで、例外, エラー, 異常などの言葉が入り乱れてて、それが広義の例外処理が誤解される原因だと思ってる — Jxck (@Jxck_) 2016年8月31日 Expected and Accepted Expected but Unaccepted Unexpected
BigQueryの新しい料金体系High Compute Queryは廃止されました。 - Qiita
High Compute Queryは2017年11月に廃止になったので、この記事は過去の思い出です。 https://cloud.google.com/bigquery/docs/release-notes?hl=en#november_14_2017 今後はBillingTierが100を超えない限りは、特に料金が変わることはありません。 BillingTier100超えはかなりの無茶をしないと出てこないので、滅多に気にすることはありません。 ただ、単純なパフォーマンスチューニングとして、以下のノウハウはまだ役に立ちます。 High Compute Queryに備える！Dremelの気持ちになって考えるパフォーマンスチューニング 以下、過去の思い出話となった内容 BigQueryのQuery料金は今までどんな複雑なクエリを書いても、データを読み込んだ容量に対して料金が決定されていました
「Swiftのこれまでの動向のまとめと今後のさらなる発展の期待」フォローアップ - iOSDC 2016 - Qiita
iOSDC 2016にて発表してきまして、そのフォローアップ記事です( ´･‿･｀) 発表直後に、こちらのMedium記事も書きました。 iOSDCで発表してきました「Swiftのこれまでの動向のまとめと 今後のさらなる発展の期待」 - Medium (公式ロゴをごにょごにょして作った改変ロゴ(問題あれば消します)) 発表内容 タイトル通り、Swiftのこれまでと今後について、15分で俯瞰出来る内容だったと思います。 こちらがスライドです: 発表動画は https://youtu.be/hkaX4274N9w?t=4h57m44s で見られます。 自作のLINEクリエイターズスタンプを駆使しています( ´･‿･｀) スライドの犬(ラヴさん)は、LINEクリエイターズスタンプになっているので、ポチっていただけるととても喜びます🙇 がんばって40種類描きました( ´･‿･｀) #iosdch
GitHubのmasterブランチをWebページとして公開する手順（GitHub Pages） - Qiita
GitHubでは、サーバーを自前で準備しなくてもWebページを公開できる「GitHub Pages」という機能があります。これまでは、gh-pagesという別ブランチを作成して、そこにソースコードをプッシュする必要がありました。しかし、本日(2016/08/18)実装された新機能により、masterブランチのみでWebページを公開できるようになりました。 本エントリーでは、具体的な設定手順を紹介します。 手順 masterブランチにて、「docs」フォルダーを作成します。このフォルダーに公開したいWebページのソースコードを入れます。 masterブランチをプッシュします。 GitHubのリポジトリページ上で、[Setting]→[Pages]に移動します。 [Source]の箇所から、「Branch: main」、「/docs」フォルダーを指定します。 [Save]を押すと、下図の赤枠部
日本の行政機関等が公開しているAPIについてのまとめ（2016年8月17日暫定版。随時更新） - Qiita
この記事は下記の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を紹介する事です。 日本の情報技術は他国と比較して、立ち遅れている部分があり、これを立て直すのが喫緊の課題であると言えます。 日本政府もこの問題に危機意識を持ち、先日、経
Seleniumアレルギーのための処方箋 - Qiita
何年も前、SeleniumやWebDriverの話で盛り上がった記憶があります。ただ、その当時はまだRailsなどバックエンド中心の文脈でした。今、フロントエンドに軸足が移る中、ブラウザテストの状況はどうなったのでしょう? 不思議なことに、フロントエンド界隈でそれほど話題に上がって来ないですよね (私の周りだけ?)。結構大事なのに。実は皆さん、「Seleniumアレルギー」なんじゃないですか? 公式サイトに漂う ゼロ年代感(下図)。Javaへの躊躇、「めんどくさい」と聞かされ続けた過去、無意識に避けてしまうのがSeleniumです。 ただ、フロントエンドの文脈でこそ、ブラウザテストは重要度を増しています。そこで「Selenium触りたくない病」の筆者が、 四苦八苦した背景 と、2016年だからこそ 見えてきた落とし所 を書いてみたいと思います。 註: 思ったより長文になってしまいました。先
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に登録
PHPの脆弱性への攻撃名称と対策メモ - Qiita
自分用メモ。ごちゃごちゃすると忘れるので、なるべくシンプルにまとめたい。 誤り、不備などあれば、随時追加修正します（ご指摘ありがとうございます）。 クロスサイトスクリプティング（cross site scripting、XSS） 概要 訪問者に目的のサイトとは別の罠サイトを踏ませて不正な処理を実行させる行為。 原因 フォームから受け取った値を、エスケープせずに画面に出力するために発生 （偽のフォームを作成する手法も有るので、JavaScriptの対策だけでは不足） HTMLの実体参照を用い、& を & に、< を < に、> を > に、" を " に、それぞれ置換する。 PHPではhtmlspecialchars関数を用いれば、一括で対策できる （ただしENT_QUOTESを設定しないとシングルクォーテーションはエスケープされない）
雨が降る・止む30分前にSlackに通知してくれるhubot用スクリプト - Qiita
はじめに hubot-slack-rainfall-alert という名前でnpmに公開しました。コードはgithubに公開しています。 CoffeeScriptというかjsも殆ど書いたことがないままとりあえず作ったので手続き型っぽくて汚いです。細かいところでも pull request 大歓迎です。よろしくお願いします。→ https://github.com/takashyx/hubot-slack-rainfall-alert/ これは何？ YahooのAPIを利用して、hubotに雨が降る前・止む前にSlackの指定したチャンネルに通知をしてくれる機能を追加します。 通知時には現在から60分後までの雨量のグラフ、30分後の雨雲の様子、より詳しい雨雲情報へのリンクを表示します。 cron形式でチェックするインターバルを指定できるので、夜中は動かさない、といった設定も可能です。 そのま
GitHubへのpush時にCodeDeployを使ってEC2にアプリケーションをデプロイする - Qiita
EC2へのアプリケーションのデプロイを考えた時に色んな候補があるかと思います。以下にまとまっていました。 AWSでデプロイとスケーリングを自動化する方法まとめ 最初、OpsWorksを検討したのですが、オートスケーリングに対応していないという点でボツとなりました。。。また、Jenkinsなどを使えば可能だと思いますが、その場合にはJenkinsをSPOFにならないように気をつけたり、AWSと連携するためにごにょごにょするのが面倒かなと思いました。 で、まだtokyoリージョンにはきていませんが、CodeDeployはオートスケーリングが対応しており、どうだろうということで色々試してみたたのでメモ。 今回の例ではGitHubへのpush時にCodeDeployを利用してEC2にWordPressのデプロイを行ってみました。 CodeDeployとは アプリケーションのデプロイを行うためのサー
AWS料金早見表
サーバレスアーキテクチャ構成にしたときに 実際のところ、どれくらいの料金になるのか気になったので算出してみようと思います。 (あくまでシミュレーションしたものでAWS側で値段や計算方法が変わったりするため、責任は負いかねますので導入する際は自己責任でお願いします。) AWSのどこにどれくらいの料金がかかっているのか知ることは大事だと思ったのですが、トータルだとなかなかまとまってなかったのでまとめてみました。 間違ってたらご指摘いただけると助かります。 サーバレスアーキテクチャって何？って方はこちら参照してください 世界に先駆けてAWSサーバレスアーキテクチャでユーザ認証とAPI認可の実装をしてみた AWSサーバレスアーキテクチャでCloudFrontからWAFをかけてAPI Gatewayを呼ぶ Lambda+RDSはアンチパターン 全部教えます！ サーバレスアプリのアンチパターン とチュ
中の人に聞いたGitHub flowの本当の使い方 - Qiita
背景 今日GitHubの中の人のLTを聞く機会があって本当のGitHub-flowを聞いてきたので 忘れない間にメモ GitHub-Flowのお約束 Masterにあるものは即座にデプロイ可能な状態に保つこと ブランチの上で必ず作業し、その生存期間を短くすること すぐにPRを作り、フィードバックやサインオフを求めること マージしたらすぐにデプロイすること 本当のGitHub-flow 中の人曰くよくマージしてからデプロイすると言っている人がいるらしい。 だが本当のGitHub-flowは違う。 本当のflowは PR作成 ⇩ 修正 ⇩ デプロイ ⇩ フィードバック ⇩ マージ らしい。 マージ前にデプロイすることでさらにユーザーに近いところでフィードバックを受けることができるとのこと。 ダメなら直ちにmasterに戻す。なので決まりごとの中にmasterは直ちにデプロイできる状態にあること
効率的に安全な Dockerfile を作るには - Qiita
結論 以下の手順で作るのが効率的です。 ベースにする Docker イメージを決める docker run -it <docker-image> sh でコンテナ内部で作業 1行ずつ、うまくいったらどこかにメモ 失敗したらいったん exit して再度 docker run ファイルの取り込みやポートの外部公開が必要ならオプション付きで docker run 全部うまくいったら Dockerfile にする ネットで見たことはないですが、もし docker build で試行錯誤しながら Dockerfile を作るとしたら、それはさすがに苦行です。 遅い デバッグしにくい！コンテナ爆発しろ！！って気持ちになります。 これが原因で「Docker 使えない 便利じゃない 」と思っていたのならそれは勘違いです。 手順詳説 試しに ip-api.com にリバースプロキシするだけの Nginx イ
dockerで一人から始める社内用ナレッジを作ってみたら周りが捗りまくった話 - Qiita
追記(2016/10/03) リリースノート眺めてたらv1.6.0でスライド対応！ 勉強会のスライドとかおけるように！ https://github.com/support-project/knowledge/releases やりたいこと Qiitaってすばらしいんだけど、社内のノウハウ蓄積にも使いたい Qiita::Team使いたいけど、開発人員が多すぎでコスト高＆保守的な会社なので許可がおりない… 使ったもの knowledge Docker Toolbox 環境 Windows7 (Corei5 8GBRAM/会社支給品) ちゃちゃっと整備 とりあえず自分用に欲しかったので 適当なディレクトリに永続化用のディレクトリを用意して、docker-compose.ymlを作る $ mkdir -p ~/docker/knowledge # docker-compose.ymlを置くディレ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
「なぜDI(依存性注入)が必要なのか？」についてGoogleが解説しているページを翻訳した - Qiita
Macで大量のmp4ファイルをmp3に変換する - Qiita
Hubot scripts の肥大化を防いで bot と気持ちのいい生活 - Qiita
EC2デプロイのためにCodeDeployを導入する - Qiita
