The Qiita Advent Calendar 2017 is supported by the following companies, organizations, and services.
![ひとりでCPUとエミュレータとコンパイラを作るのカレンダー | Advent Calendar 2017 - Qiita](https://cdn-ak-scissors.b.st-hatena.com/image/square/091ee0745e55e3824e66d171b31ea23be19ec3d0/height=288;version=1;width=512/https%3A%2F%2Fqiita-user-contents.imgix.net%2Fhttps%253A%252F%252Fcdn.qiita.com%252Fassets%252Fpublic%252Fadvent_calendar%252Fogp%252Fcalendar-ogp-background-c24e7570f8dc39b6f4e1323cbd83d11f.jpg%3Fixlib%3Drb-4.0.0%26w%3D1200%26mark-x%3D142%26mark-y%3D128%26mark64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ0eHQtYWxpZ249bGVmdCUyQ3RvcCZ0eHQtY29sb3I9JTIzRkZGRkZGJnR4dC1mb250PUhpcmFnaW5vJTIwU2FucyUyMFc2JnR4dC1zaXplPTU2JnR4dD0lRTMlODElQjIlRTMlODElQTglRTMlODIlOEElRTMlODElQTdDUFUlRTMlODElQTglRTMlODIlQTglRTMlODMlOUYlRTMlODMlQTUlRTMlODMlQUMlRTMlODMlQkMlRTMlODIlQkYlRTMlODElQTglRTMlODIlQjMlRTMlODMlQjMlRTMlODMlOTElRTMlODIlQTQlRTMlODMlQTklRTMlODIlOTIlRTQlQkQlOUMlRTMlODIlOEIlMjBBZHZlbnQlMjBDYWxlbmRhciUyMDIwMTcmdz05MTYmcz00ZjMyMDU5NmM1YTcyZGY4MTdmM2NkNTBjMjVkMDc5ZQ%26blend-mode%3Dnormal%26blend-x%3D142%26blend-y%3D491%26blend64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ0eHQtYWxpZ249bGVmdCUyQ3RvcCZ0eHQtY29sb3I9JTIzRkZGRkZGJnR4dC1mb250PUhpcmFnaW5vJTIwU2FucyUyMFc2JnR4dC1zaXplPTM2JnR4dD0lNDBrYWl0b3Vfcnlha3Umdz05MTYmcz0xMDFmNTkxN2RiNjljNzQ2ZDhkZjllZDBhNzFiNjZjOA%26s%3D8abd65e9c8fa9c5ea72cab2a9f60170d)
The Qiita Advent Calendar 2017 is supported by the following companies, organizations, and services.
Webエンジニアの横塚です。 皆さんは情報共有ツールは利用しているでしょうか。 LCLエンジニアチームでは先日、以前から利用していたQiita:Teamからesa.ioに移行することにしました。 移行の背景と、実際に移行してみてどうだったかを簡単に紹介したいと思います。 teams.qiita.com docs.esa.io 移行しようと思った理由 Qiita:Teamは本来やりたかったwiki的な使い方にあまり合ってなかった LCLでは、システム仕様や、共有しておきたい知見、定例MTGの議事録などをQiita:Teamの記事に溜めてきました。記事には必ずタグ付けをしておき、関連記事はタグで検索できるようにしていました。しかし、記事が増えていくにつれ、その運用も限界を迎えていました。 記事が増えすぎた結果、タグが形骸化し、キーワード検索をするしかない状況になりました。 慣れている人はいいで
動機 RancherOS を使って、k8s (kubernetes) 環境が簡単に構築できた けど、ストレージ周りはどうしよう 手元では NFS を提供するための VM を立てたけど、負けた気がする (:3」∠)_ 分散ストレージで組めたら、かっこいいなぁ 調査前は Glusterfs くらいしかクラスタ組んだことがなかった と、思って調べてみたのでアウトプットです。 試したわけではなく、まだ俯瞰しただけです(´・ω・`) k8s (kubernetes) で利用可能なストレージ まずは、何が使えて、何が使えないのかを調べます 調査対象にする条件 手軽に試せそう(OSS とかわざわざ購入しなくても良さそうなもの) オンプレ (クラウドは手軽に試せるし、動かしても「ふーん」で終わってしまうので) で、公式ドキュメントを見てみました https://kubernetes.io/docs/con
【背景】 この記事はQuoraの「What does a CTO do?」という質問に対するAmr-Awadallah氏のよくまとまった回答の翻訳です(本人から許可取得済)。 私はMAMORIO株式会社でCTOをしているのですが、最近自分の仕事が何なのかよく分からなくなってきたことがこの記事を書こうと思ったきっかけです。 私はこの記事でいう所の「雑草CTO」であり、たまたま会社の初期に私以外に適任者がいなかったので成り行きで就任し現在に至ります。 そして、人数もプレッシャーも少ない総初期は来た玉は打つの姿勢でコーディングから渉外まで何でもこなしていましたが、メンバーが増え、それよりも早いペースでユーザーと仕事が増えてくると、自分の職務を定義しやることとやらないことをはっきり分ける必要が出てきます。 この翻訳が同じような状況にあるCTOの助けになればと思いますし、誤訳等があったら指摘してくだ
2018年8月、東京医科大学が女性受験者を一律で減点していたことが発覚し、大きな議論を呼んでいます。 東京医大、女子受験者を一律減点 入試で不正操作、3割に抑制 Python で仮説検定をして確かめてみましょう。 各医科大の男女別受験者・合格者数 医科大の男女別受験者・合格者数を Twitter の @hkazeno さんが一覧にしてくださったので、それを使わせていただきます。(@mad_molizさん、@hkazenoさん、感謝申し上げます。私はツイッターアカウントを持っていないため、事前に許可を求めるリプライを送りませんでした。失礼をお詫びします。) データを抜粋して CSV ファイルにします。すべてのソースを確認してはいませんが、2018年度の受験結果だと思われます。(東京医科大の数値がソース不明だったので、報道記事をもとに2018年度入試結果に書き換えました。) 大学名,男子受験者
TL;DR; Amazon AuroraはIn-Memory DBでもなくDisk-Oriented DBでもなく、In-KVS DBとでも呼ぶべき新地平に立っている。 その斬新さたるやマスターのメインメモリはキャッシュでありながらWrite-BackでもなくWrite-Throughでもないという驚天動地。 ついでに従来のチェックポイント処理も不要になったのでスループットも向上した。 詳細が気になる人はこの記事をチェキ! Amazon AuroraはAWSの中で利用可能なマネージド(=運用をAWSが面倒見てくれる)なデータベースサービス。 ユーザーからはただのMySQL、もしくはPostgreSQLとして扱う事ができるのでそれらに依存する既存のアプリケーション資産をそのまま利用する事ができて、落ちたら再起動したりセキュリティパッチをダウンタイムなしで(!?)適用したりなどなどセールストー
去年のAdvent CalendarでJupyter+Ansibleを使ったインフラ運用の下準備と書かせていただいたわけですが、今年も1年通してJupyterを使った運用をさせていただきつつ、組織外の方々もこのやり方に巻き込ませていただいたりしていました。 で、この巻き込ませていただく取り組みの中で、Jupyter+Ansibleを使ったインフラ運用の何が伝わりずらい/誤解を招きやすいのかがなんとなく識別できてきた気がするので、ここはあえて(懲りずに)今年も同じタイトルで書かせていただきたいと思った次第です。 何が問題なのか? これまでの記事は道具から入ってしまっていて、問題意識がイマイチ伝わりづらい感じがしていました。ので、今年はまずは問題意識から。 Automation の罠 まず、あまりたくさんの仕事はしたくありません。人手も足りないし。そのくせなんだかクラウドが自然なものとして定着
コミュニティガイドライン行動指針 ‐ Qiitaの目指す世界 エンジニアにとって再利用性・汎用性の高い情報が集まる場をつくろう Qiitaはエンジニアにとって再利用性・汎用性の高い他のユーザーにとっても役にたつ、学びのある情報が多く集まっている場であり続けたいと考えています。 Qiitaは記事を読むこと、記事を書くことを通して、読む側・書く側それぞれがお互いに関わり合いを持ち、情報をみんなで育てていくことで、今後同じようなことを学んだり、悩んだりするエンジニアが使う時間を減らし、エンジニアの成長や生産性をスピードアップさせることを目指します。 「あなた」と「誰か」がつながる場としていこう あなたが記事を読んだり、書いたりすることは、その行為だけにとどまらず、記事を通して誰かとつながるきっかけとなります。同じ分野に関心を持っている方やスキルセットが似たような方と、Qiitaの記事を通してつな
サーバーのメモリが slab_cache で占有される サーバーのメモリが数日で slab_cache に占有されるので原因と対策を調査した。 メモリの使用状況の調査 meminfo meminfo を見ると Slab のメモリ使用量が確認できる。 SReclaimable と SUnreclaim を足すと Slab になる。 $ cat /proc/meminfo | grep "Slab\|claim" Slab: 1654520 kB SReclaimable: 1631304 kB SUnreclaim: 23216 kB slabtop slabtop コマンドをたたくと top コマンドのように Slab の内訳が表示される。 dentry が最も多いようだ。 --once は1回出力で終了するオプション。 --sort=c はキャッシュサイズ順にソートするオプション。 sl
弊社に5年間在籍していたロシアの天才ハッカーが先日退職しました。 ハッキング世界大会優勝の経歴を持ち、テレビ出演の経験もある彼ですが、正直こんなに長く活躍してくれるとは思っていませんでした。彼のようなタレントが入社した場合、得てして日本の大企業にありがちな官僚主義に辟易してすぐに退職するか、もしくはマスコットキャラとして落ち着くかのどちらかのケースがほとんどなのですが、彼は最後まで現場の第一線で活躍してくれました。 そんな彼が最後に残していった退職メールがなかなか印象的だったので、その拙訳をここに掲載します(転載について本人同意済み。弊社特有の部分は一部省いています。) ああ、なんという長い旅だったろう。この会社で5年間もセキュリティを担当していたよ(諸々の失敗は許してくれ) 俺は他の退職者のように面白いことは書けないが、私のこの退職メールを読んでくれている人、特に新人エンジニアのために、
画像: N高等学校課外授業(N予備校)での生放送授業のブラウザ上での見た目、コメントが書ける 目次 はじめに 教えることになったきっかけ Web企業にエンジニアとして就職できるようになる、というミッション 既存のWeb教材に感じた問題意識 「各自進められるゲームブック形式の教材」と「徹底的にフォローする生放送授業」 コンセプトをもとに構成されたコースと内容 ゼロからプログラミングができるようになった人が生まれた日 永劫、プログラミングは一部の天才たちのためのものか? プログラミング学習のモチベーションの課題と対応 まじめなオタクたちが社会をよくしようと頑張ること さいごに はじめに 自分はこの8ヶ月間、Web上で非対面のプログラミング教育、具体的にはHTML教材と生放送授業を中心としたプログラミング教育をN高等学校の生徒に行ってきました。 ここに書かれている内容は、これからプログラミング教
おしながき メンバーは3〜5名、協力企業は1〜2名の小規模チーム メインは某小売店の大規模ECサイト案件統括(開発は外部委託) サブで基幹連携等を担う周辺業務システム開発・運用 マネジメントが上手く回らず高残業が常態化。PM前任者異動に伴い、部下だった私にお鉢が回る 上長指示により残業削減へ そんな2〜3年前のお話です。 改善"前"のタスク運用 ※あくまで改善"前"の話です。 基本はRedmine + Kanbanプラグインでタスク(チケット)運用。 ナレッジ可視化の意識付けも目的の一つだったので、以下を徹底した。 作業に伴うタスク発行の徹底 進捗状況の逐次反映 そして、運用ルールの入念な教育(五十六メソッドを採用した) 当時はITSベースのタスク管理自体が社内で先進的な試みだったので、当時部下だった私もPMと協力して「できるだけ丁寧な運用」を心がけた。心がけた、のだが… おかしいな だれ
若手エンジニアを不幸にしないための開発の「べからず」集 組織運営編から記事を独立させました。 優秀な技術者ほど辞めてしまいやすいのは、多くの会社に共通していることです。 この文章では、どうして優秀な技術者が辞めていってしまうのか、その理由を探るとともに、そうならないようにするための対処方法を少しずつ書き足していきたいと思っています。 マネジャーのみなさんへの前書き 会社の資産であるソースコードはきちんと管理されてますか? 「きちんと金庫にしまってある」ではありません。 開発が進みやすく、今のソースコードはどのように品質が保たれているのかがわかるようになって 管理されてますか。 ソフトウェアの開発などで生じている課題は、どのように管理されていますか。 「去年の△月ごろに問題になっていたあの件は、結局どうなったのかい。」 「担当していた○○さんがだったら知っているんですけれども、もうやめちゃい
ディープラーニングは特定分野で非常に高い精度が出せることもあり、その応用範囲はどんどん広がっています。 しかし、そんなディープラーニングにも弱点はあります。その中でも大きい問題点が、「何を根拠に判断しているかよくわからない」ということです。 ディープラーニングは、学習の過程でデータ内の特徴それ自体を学習するのが得意という特性があります。これにより「人が特徴を抽出する必要がない」と言われたりもしますが、逆に言えばどんな特徴を抽出するかはネットワーク任せということです。抽出された特徴はその名の通りディープなネットワークの中の重みに潜在しており、そこから学習された「何か」を人間が理解可能な形で取り出すというのは至難の業です。 例題:このネットワークが何を根拠に猫を猫として判断しているか、ネットワークの重みを可視化した上図から答えよ(制限時間:3分) image from CS231n Visua
RESTful な URL にしよう 元記事 GET /tickets - チケットのリストを取得する GET /tickets/12 - 指定したチケットの情報を取得する POST /tickets - 新しいチケットを作成する PUT /tickets/12 - チケット #12 を更新する PATCH /tickets/12 - チケット #12 を部分的に更新する DELETE /tickets/12 - チケット #12 を削除する Google GET /events - 予定のリストを取得する GET /events/12 - 指定した予定の情報を取得する POST /events - 新しい予定を作成する PUT /events/12 - 予定 #12 を更新する PATCH /events/12 - 予定 #12 を部分的に更新する DELETE /events/12 -
はじめに 「達人に学ぶDB設計」、「SQLアンチパターン」を読んだのでDB設計をする流れとその過程でのチェックポイントをまとめてみました。 今回は本に載っているものの中でも特に重要そうな部分に絞ってみました。 さらに詳しいことを知りたい方は本を購入してみてください。個人的には達人に学ぶDB設計徹底指南書のほうがおすすめです。こちらだけあれば十分だと思います。 DB設計には大きく分けて論理設計と物理設計の二つがありますが、今回はアプリケーション開発でメインとなる論理設計の部分に焦点をあてて説明をします。 一番最後にチェックポイントだけをまとめた章を用意したので、チェックポイントだけ知りたい方は最後だけ見ていただければと思います。 DB論理設計の流れ DB論理設計は以下のようなステップで進めていきます。 エンティティの抽出 エンティティの定義 正規化 ER図の作成 以下では各ステップごとに章を
追記 2018年の機械学習勉強法などをまとめました! 2018年版もっとも参考になった機械学習系記事ベスト10 はじめに 2016/12/14 から約1ヵ月間、機械学習の勉強をし続けました。これは会社の自由研究という制度を利用させて頂いて、1ヶ月間は業務から離れて、機械学習の勉強だけをやり続けた記録です。 勉強してきたもののうち教師あり学習までは、Qiita にその記録をまとめましたので過去記事一覧からご覧ください。 過去記事一覧 1日目 とっかかり編 2日目 オンライン講座 3日目 Octave チュートリアル 4日目 機械学習の第一歩、線形回帰から 5日目 線形回帰をOctave で実装する 6日目 Octave によるVectorial implementation 7日目 ロジスティック回帰 (分類問題) その1 8日目 ロジスティック回帰 (分類問題) その2 9日目 オーバーフ
ディープラーニングの有名ライブラリ5種を最短距離で試す半日コース(TensorFlow, Chainer, Caffe, DeepDream, 画風変換)Python画像処理機械学習DeepLearningTensorFlow 「いつか勉強しよう」と人工知能/機械学習/ディープラーニング(Deep Learning)といったトピックの記事の見つけてはアーカイブしてきたものの、結局2015年は何一つやらずに終わってしまったので、とにかく一歩でも足を踏み出すべく、 本質的な理解等はさておき、とにかく試してみる ということをやってみました。 試したのは、TensorFlow、Chainer、Caffe といった機械学習およびディープラーニングの代表的なライブラリ/フレームワーク3種と、2015年に話題になったディープラーニングを利用したアプリケーション2種(DeepDream、chainer-g
10年以上金融機関で働いているインフラエンジニアの落ちないサーバにするための考察です。 ハードウェアの専門家ではないので、正確ではないかもしれません。 今までの経験からの個人的考え方になります。 私たちオンプレ重視のインフラエンジニアは、 クラウドサービスではできない高可用性サーバを導入したり、 複数台構成で1台故障しても問題ない構成のサーバはコスト重視するなど、 システムに最適なサーバを導入しようとしています。 高可用性サーバを追求する目的 ■アプリに影響を与えないように Active/Standby構成にしていて、インフラ的にはダウンタイムが数秒だとしても、 アプリによっては復旧に時間がかかったり、問題ないことの確認にも時間がかかってしまいます。 また、正しくサーバが落ちればアプリが問題ないとしても、 サーバが中途半端な状態のままになってしまい、なんだかおかしいということもあります。
【2021/10/15 追記】 この記事は更新が停止されています。現在では筆者の思想が変化している面もありますので,過去の記事として参考程度にご覧ください。PDO に関しては大きく変わっていない部分が多いとは思いますが, PHP 8.x 以降での動作保証はありません。 あらかじめ読んでおきたい記事 Qiita - 【PHP超入門】クラス~例外処理~PDOの基礎 by @7968 初心者がやりがちなミス 以下のどれかに1つでも当てはまるコードは見直す必要があります.付録にリンクを貼っておきましたので,「該当するかも?」という人はクリックして飛んで読んでください.太字にしてあるものは脆弱性に直結する危険度の高いものです. mysql_query などの非推奨関数を利用している SET NAMES あるいは SET CHARACTER SET などで文字コードを指定している そもそもデータベース
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く