タグ

2015年12月24日のブックマーク (10件)

  • メール運用がロストテクノロジーになっていく話

    クラウドワークス Advent Calendar 17日目担当のSMTPおじさんの記事です。 時間の無い人のために3行でまとめますと以下のコンテンツでお送りします。 大規模なメール配送を安全に行うには特別なノウハウがあり罠も多い SendGrid便利です 当たり前になった技術は空気のように見えなくなってインフラ化する。それがある日突然失われたときの被害は甚大。インフラ技術をキャッチアップして備えよう メール配送今昔 さて、メール配送といえば古くはSendmailを使っていました。多くのUnixディストリビューションに標準でインストールされており、使うのが当たり前で選択肢も少なかった時代です。 Sendmailは開発が重ねられることで複雑化しセキュリティホールが頻発しました。また設定ファイルのsendmail.cfはチューリング完全であるほど高機能で複雑でまた長くなりがちでもあり今でも書きた

    メール運用がロストテクノロジーになっていく話
  • 年45万円の出費!本当にヤバい実家の相続

    コンテンツブロックが有効であることを検知しました。 このサイトを利用するには、コンテンツブロック機能(広告ブロック機能を持つ拡張機能等)を無効にしてページを再読み込みしてください。 ✕

    年45万円の出費!本当にヤバい実家の相続
  • 初心者がAWSでミスって不正利用されて$6,000請求、泣きそうになったお話。 - Qiita

    こんにちは、2015年も終わりですね。昨年よりエンジニアのお仕事をはじめております自称エンジニアの@mochizukikotaroです。 お祭り記事ですので、皆様の箸休めの一助にでもなればと思いながら、全力で書きたいと思います。 まず感謝 当記事は、「素人がAWSに手を出し、のんきに過ごして気づいたら、自分のミスで不正利用され$6,000ほどの請求が来ていて」一週間ほどべ物も喉を通らず、AWS様に泣きついた結果、「なんとか情け容赦を頂いた」という内容です。 文中には多少ふざけた言葉選びが散見されるかもしれませんが、私は全力で AWSさんに感謝 をしております。 この先、 僕と同じような過ちを犯す可哀想な素人エンジニアを、この世から一人でも無くしたい。 と切に願っております。 最初にお断りしておきますが、 当記事から得られる、プログラミングインテリジェンスは1gくらいです。 一定レベル以

    初心者がAWSでミスって不正利用されて$6,000請求、泣きそうになったお話。 - Qiita
  • 銀行員にダマされないための正しいマネー運用マニュアル(山崎 元) @gendai_biz

    父親らしき男性(実際には近所の電通マンで、アカの他人だったが)に肩車された男の子が空を見上げている。コピーは「大きく育て!」と「ボーナスでつくるくらしの土台」の2つだ。 これは、約50年前の北海道拓殖銀行(地元では「たくぎん」と呼ばれていた)の「すずらん定期」という商品名の定期預金のポスターだ。そして、実は、肩車に乗っている男の子は子供の頃の筆者なのだ。 この頃、銀行は定期預金を中心に預金集めに力を入れていた。日銀のホームページの「主要金利」の表で当時の金利を見ると、公定歩合が6.57%、普通預金が2.19%だから、定期預金はこの間くらいの利息が付いていたのだろう。 インフレとの競争がどうかという問題はあっても、「貯金しよう」という意欲がそこそこに湧く金利が付いていた。 北海道拓殖銀行は後に破綻する訳だから(政府の判断によって預金者は損をしなかったが)、完全に安心してお金を預けていて良かっ

    銀行員にダマされないための正しいマネー運用マニュアル(山崎 元) @gendai_biz
  • ニコニコ動画の公開コメントデータをDeep Learningで解析する - Qiita

    この記事は第2のドワンゴ Advent Calendar 2015の24日目の記事です。 ドワンゴエンジニアの@ixixiです。 niconicoのデータをDeep Learningなアプローチで解析してみた話です。 nico-opendata niconicoの学術目的用データ公開サイト https://nico-opendata.jp が最近オープンしました。 これまでも、国立情報学研究所にて、ニコニコ動画コメントデータや大百科データが公開されていましたが、 nico-opendataでは、ニコニコ静画のイラストデータの約40万枚のイラストとメタデータが研究者向けにデータ提供されています。 今回は、ニコニコ動画コメントデータ(誰でも取得可能)を用いたDeep Learningによるコメント解析例を紹介します。 超自然言語 ニコニコのコメントデータに限らず、twitterでのtweetや

    ニコニコ動画の公開コメントデータをDeep Learningで解析する - Qiita
  • ダレずに開発を走り切る為の習慣

    重要なのは、この「煩わしさ」は、「そのタスクを完了した際に、どれだけ体力と意欲を使い果たすか」 の指標であることです。 「技術的には難しくないから、経験の浅い人にまとめてやってもらおう」と、そうした「だるいタスク」を集中させてしまうと、あっという間に人員が疲弊して 最悪離職します 恥ずかしながらこういう経験があります。 「だるさ見積り」した => 予測工数の -5%〜+5% の前倒しor遅延 で済んだ 「だるさ見積り」しなかった => +20%〜40% も遅延した。 終わった後の生産性の低さも当にもう酷かった。 ごめんなさい。。。。 やろう!『だるさ』見積り!当に大事だよ! [見積もり編] 3. OKR を意識したバックログ 具体的には Github の issue サマリを記載していく事柄で実践します Objectives : この PullRequest で何ができてほしいのか サ

    ダレずに開発を走り切る為の習慣
  • 《ブログ年収250万を超えて》SEOと収益化のために僕が実践してきたこと - Literally

    2015 - 12 - 23 《ブログ年収250万を超えて》SEOと収益化のために僕が実践してきたこと WEB TIPS 6ヶ月ぶりの更新になる。 2015年、ぼくはこのブログで11記事だけ書いた。それでも2015年のブログ収入は250万円を超えた。25〜30万円/月がブログの収入として入ってきている。このまま放置していても、しばらくは同程度の収入が入ってくるだろう。 ぼくには会社員という業がある。いまは某外資系に勤めている。あくまでもブログはぼくの自分の思考や知識をまとめるためのトレーニングツールだ。趣味のひとつとも言えるだろう。副業というほど、肩に力は入っていない。単純に多くの人に読んでもらえるのは嬉しい。戦略を立て、その戦略がハマり、結果として収入があるのは嬉しい。だからぼくはブログを書く。 この1年間は少々忙しかったため殆ど更新できずにいたが、来年からまた再開していこうと思う。

    《ブログ年収250万を超えて》SEOと収益化のために僕が実践してきたこと - Literally
  • Go最後の秘宝「GUI」を探しに行く - Qiita

    Golangができること、むしろ「得意」と言われるものはすでにたくさんあります。 クロスコンパイルが得意だし依存が少ないバイナリができるから、いろんな環境で使えるコマンドラインツールを書くにはGoがいいよ パフォーマンスが高いし文字列処理もやりやすいので、高速なAPIサーバが得意。gRPCでもHTTP/2でも Webアプリケーション・フレームワークも増えてきていてウェブサービス作れるよ ビルドシステムとパッケージマネージャ内蔵なので、gitから簡単にパッケージをダウンロードしてきたり、◯makeコマンドとか◯runtとか◯owerで消耗しなくて済む gopher.jsでJavaScriptにもなる 逆に今まであまり良い解がなくて、「Goにはちょっと不向きだね」と言われ続けていたのがGUIです。鳴り物入りで出てきたGXUIが開発が止まってしまい、それと同じぐらいにshinyというものが開発が

    Go最後の秘宝「GUI」を探しに行く - Qiita
  • ブラウザから手軽に深層学習AIを教育できるオープンソースソフトウェア

    ブラウザから手軽に深層学習AI教育できるオープンソースソフトウェア You can train a deep neural network on your web browser 2015.12.24 Updated by Ryo Shimizu on December 24, 2015, 06:00 am JST 先日発表した深層学習(ディープラーニング)をWebブラウザ上から手軽に行うためのオープンソース・ソフトウェア、「DEEPstation(ディープステーション)」をついに公開しました。現在、Githubより誰でもダウンロードして使用することが出来ます(https://github.com/uei/deepstation)。 DEEPstationは、ディープラーニングを手軽に実験するためのGUIベースのアプリケーションで、以下のような特徴があります。 国産ディープラーニングフレ

    ブラウザから手軽に深層学習AIを教育できるオープンソースソフトウェア
  • Rails のアーキテクチャ設計を考える - Qiita

    はじめに ここ一年くらいずっと Rails の何がダメでどうすれば良くなるのかを考えていました。 Rails を使ってそれなりの規模のアプリケーションを作ったことがある人なら、メンテナンスのしづらさを感じたことがあるのではないでしょうか。 メンテナンスの問題は Rails 以外の開発でも発生することですが、実のところメンテナンスしやすいアプリケーションはどうすれば作れるのでしょうか? この難問に対して私も答えを持っていませんが、考え続けています。 少なくとも、 Rails Way や Rails Tutorial をベースにしたアプリケーション開発は、業務で用いるには簡単すぎるように思います。 「レールに乗る」という言葉がありますが、私は考え方を変えました。 Rails は規模の大きいフレームワークですが、土台に過ぎません。 Rails Way の設計方針は小規模な開発では有効ですが、規模

    Rails のアーキテクチャ設計を考える - Qiita