タグ

2017年12月26日のブックマーク (13件)

  • 「白雪姫」を目覚めさせる王子さまの「キス」、準強制わいせつ罪にあたる? - 弁護士ドットコムニュース

    「白雪姫」を目覚めさせる王子さまの「キス」、準強制わいせつ罪にあたる? - 弁護士ドットコムニュース
    progrhyme
    progrhyme 2017/12/26
    確かに。
  • Qiitaを運営するIncrementsのエイチームグループ入りについて

    開示のあった先週金曜日に個人のTwitterやFacebookで簡単に書きましたが、弊社よりQiita, Qiita:Teamを運営するIncrementsは2017/12/25より株式会社エイチームの完全子会社となり、エイチームグループへ加わることとなりました。 株式会社エイチームによる Increments 株式会社の全株式取得について — Increments株式会社 Twitterでは多くの方に言及していただき、「買収」ということに対して不安に思われているQiitaのユーザーさんもいらっしゃるようですが、Incrementsが引き続きQiitaやQiita:Teamを提供し改善し続けること、今後もエンジニアを幸せにするサービスや事業に取り組むことは変わりません。株式会社エイチームは経営理念として「みんなで幸せになれる会社にすること」を掲げていますが、その中でも社内外のエンジニアに対

    progrhyme
    progrhyme 2017/12/26
  • gitbookで設計書を作成したら最高だった話 - フォトシンス エンジニアブログ

    こんにちは。Akerunエンジニアの @ishturk です。 Akerun Advent Calendarの記事です。 今日は設計書の話です。 設計書をどんなツールで書くかは、僕らソフトウェアエンジニアの尽きない悩み(楽しみ)ですね。 最近はまったツールが最高に良かったので紹介させてください。 僕のツールに求める要件は以下です。 編集がカジュアルにできる UMLが書ける。あとから編集できる(画像での貼付けは編集できないのでNG) バージョンの管理ができる 好きになれる(重要) 変遷と pros/cons MS Word pros 良くも悪くもスタンダードなツールですね。 だれでも編集できるのが強みです。 Visioと組み合わせれば、UMLも後から編集可能です cons Visioは標準にするには少々値が張ります。 バイナリ形式なのでバージョン管理はしづらいです。 ページが増えたり画像を貼

    gitbookで設計書を作成したら最高だった話 - フォトシンス エンジニアブログ
    progrhyme
    progrhyme 2017/12/26
  • イマドキのJavaScriptの書き方2018

    PySpa統合思念体です。これからJavaScriptを覚えるなら、「この書き方はもう覚えなくていい」(よりよい代替がある)というものを集めてみました。 ES6以降の難しさは、旧来の書き方にプラスが増えただけではなく、大量の「旧来の書き方は間違いを誘発しやすいから非推奨」というものを作り出した点にあります。5年前、10年前のやウェブがあまり役に立たちません。なお、書き方が複数あるものは、好き嫌いは当然あると思いますが、あえて過激に1つに絞っているところもあります。なお、これはこれから新規に学ぶ人が、過去のドキュメントやコードを見た時に古い情報を選別するためのまとめです。残念ながら、今時の書き方のみで構成された書籍などが存在しないからです。 たぶん明示的に書いていても読み飛ばす人はいると思いますが、すでに書いている人向けではありません。これから書くコードをこのスタイルにしていくのは別にいい

    イマドキのJavaScriptの書き方2018
    progrhyme
    progrhyme 2017/12/26
    たまにしかJS書かない僕にありがたいまとめ。
  • 分散型グラフデータベース「Dgraph 1.0」リリース、初のプロダクションリリースに | OSDN Magazine

    12月19日、オープンソースのグラフデータベース「Dgraph 1.0」がリリースされた。Dgraphは高速で拡張性のある分散型グラフデータベースで、「世界で最も先進的なグラフデータベース」だという。 Dgraphは水平方向の拡張性に優れた分散グラフデータベース。ACIDトランザクション、Raftベースの一貫性のあるレプリケーション、高い可用性などを特徴とし、ディスク上でのデータの配列を制御することでクエリの性能やスループットを最適化する。FacebookのGraphQLライクなクエリシンタックスをサポートし、GRPCとHTTPを介してJSONとProtocol Buffersでレスポンスする。 元Google社員が2015年にスタートしたネイティブなグラフデータベースプロジェクトで、テラバイド級の構造化データからリアルタイムのユーザークエリに対応する低レベルの遅延も目指す。 プロジェクト

    分散型グラフデータベース「Dgraph 1.0」リリース、初のプロダクションリリースに | OSDN Magazine
    progrhyme
    progrhyme 2017/12/26
  • kopsを使ってKubernetesクラスタをAWS上で構成 | Amazon Web Services

    Amazon Web Services ブログ kopsを使ってKubernetesクラスタをAWS上で構成 この記事では、KubernetesクラスタをAWS上で構成し運用するツールの1つであるkopsを利用すると、簡単にKubernetesを始められることをご紹介します。なお最新情報は、GitHubで公開しているAWS Workshop for Kubernetesをご覧頂き、さらに構築したクラスタを使って様々なワークショップをご自身の手で試して頂くことをお勧めします。 kopsについて Kubernetesのトップレベルプロジェクトで、Kubernetesのクラスタを構成し運用するためのツールです。また、クラスタのローリングアップデートや、アドオンもサポートしています。必要に応じて、AWS CloudFormationやTerraformのテンプレートを出力することもできるので、それ

    kopsを使ってKubernetesクラスタをAWS上で構成 | Amazon Web Services
    progrhyme
    progrhyme 2017/12/26
  • TimeFuzeアーキテクチャ構想 - 処理とデータとタイマーを一体化したデータパイプライン - ゆううきブログ

    この記事は第1回ウェブシステムアーキテクチャ(WSA)研究会の予稿です。 cronのようなタイムスケジューラーにより、定期的に実行されるバッチ処理の課題を解決するアーキテクチャを最近考えている。 この記事では、単一のタイムスケジューラによるcronベースの手法に代えて、データに対してタイマーと処理を仕込むことでスケールさせやすい構造にできないか、という提案を試みる。 はじめに Webサービスにおいて、リクエストに対してHTMLのレスポンスを返却する以外のワークロードの多様化が進んでいる。 最近であれば、機械学習による時間周期による大規模なデータ処理が求められることも多い。 その他、月次の課金バッチ処理や、ランキングの定期更新など、一定の時間間隔で任意の処理を実行したいケースは多い。 このような定期的なデータ処理パターンは、SRE[Bet17]の25.1節「パイプラインのデザインパターンの

    TimeFuzeアーキテクチャ構想 - 処理とデータとタイマーを一体化したデータパイプライン - ゆううきブログ
    progrhyme
    progrhyme 2017/12/26
    レコード単位タイマー付のTriggerシステム。TTLをフックにするのは難しそう
  • Redash Meetup #0.1 - Redash 初心者向けハンズオン (2018/01/30 19:00〜)

    内容 Redash Meetup #0 - Redash 初心者向けハンズオン の再演です。 オープンソースのデータ可視化ツール Redash をハンズオン形式で学べる勉強会を開催します。 ハンズオンでは、環境構築からクエリやダッシュボード作成、活用の Tips などを体験できます。 当日は、GitHub にて公開されている「Redash ハンズオン資料」 https://github.com/kakakakakku/redash-hands-on を活用し、各自のペースでハンズオンを進めていただきながら、疑問点、不明点を講師がお答えしつつ進行する、半もくもく会スタイルになります。 想定参加者像 Redash がどのようなツールか調べたことはあるが、まだ触ったことがない Redash の導入を検討しているが、どんなことができるか知りたい Redash のデモを触ったことがあるが、自分でも検

    Redash Meetup #0.1 - Redash 初心者向けハンズオン (2018/01/30 19:00〜)
    progrhyme
    progrhyme 2017/12/26
    1/30に先日のハンズオンの再演があるようです。
  • Engineering Team in Mercari 2017 | メルカリエンジニアリング

    Happy Holidays、みなさまいかがお過ごしですか。エンジニアブログでは久々の @sotarok です。こんにちは。 この記事は Mercari Advent Calendar 2017 最終日の記事となります。昨日は Engineering Operations Team (EOT) の @jollyjoester から、”技術コミュニティを支援する「Mercari Tech Sponsorship Program」” をお送りしました。 いよいよ最終日となりましたが、今日は私目線で、メルカリのプロダクトと開発組織について、今年起こったことのまとめをお送りします。 メルカリは、昨年12月時点で70名 (海外拠点・ソウゾウ含め) ほどだったエンジニアも、200名を超える規模にまでなってきています。この1年、組織面含め多くのことが起こりました。主だった出来事を、かいつまんでお届けでき

    Engineering Team in Mercari 2017 | メルカリエンジニアリング
    progrhyme
    progrhyme 2017/12/26
  • 教育×見える化!3つの高校大学でグラフィックレコーディング授業をしてみて見えてきたもの|わなみん

    1. 高校や大学でどんな授業を行ったか(島田商業高校、明治大学、千葉大学) 2. なぜ学校で可視化の授業を実施するのか 3. 可視化授業の今後の野望 こちらはグラフィックレコーディングのアドベントカレンダーの記事です。 私は普段はアプリ開発してるデザイナーですが、2014年からグラフィックレコーディングの活動もしています。高校大学で可視化の授業を行っているので、どんな授業をなぜやってるかを振り返ろうと思います。 1. 高校や大学でどんな授業を行ったか2015年頃から全国各地でグラフィックレコーディング勉強会という団体を仲間と立ち上げて体験ワークショップを開いたりしてたんですが、これらの可視化体験のワークを大人ではなく学生向けにやってみたらどうだろう?と"グラフィカシー"という言葉を恩師から学んだこともあり、ここ2年程挑戦しています。 静岡県立島田商業高校 情報クラス情報デザイン専攻(高校2

    教育×見える化!3つの高校大学でグラフィックレコーディング授業をしてみて見えてきたもの|わなみん
    progrhyme
    progrhyme 2017/12/26
  • ユーザー理解はどこまでできるのか?

    ヤフー株式会社は、2023年10月1日にLINEヤフー株式会社になりました。LINEヤフー株式会社の新しいブログはこちらです。LINEヤフー Tech Blog はじめに メリークリスマス! マーケティングソリューションズカンパニーのリサーチアナリシス部に所属している田中です。 今日はコンバージョン予測の紹介と考察を行っていきます。 まず、コンバージョン予測を選んだ理由について説明いたします。私は、ヤフーに広告を出稿していただいている広告主の課題を解決する部署に所属しているので、広告主の課題のひとつであるコンバージョン獲得をテーマにしました。 広告主の課題をコンバージョン獲得と仮定すると、そのためにヤフーとしてはユーザーがコンバージョンをするのかどうかを理解する必要があります。 コンバージョン予測はマーケティングへの適用範囲が広く、予測確率の高いユーザーに広告を配信したりそのユーザーの動き

    ユーザー理解はどこまでできるのか?
    progrhyme
    progrhyme 2017/12/26
    コンバージョン予測
  • Reactを使って本気でアンケートシステムをつくった - Qiita

    Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? この記事は エムスリー Advent Calendar 2017 の25日目の記事です。 普段はDB・サーバサイド・クライアントサイドまでの設計・実装・運用を扱っていますが、この記事ではReactを使って開発したシステムについてを紹介しようと思います。 作ったもの アンケートシステム(survey-designer-js)を作り、社内で使っていました。またOSSとしてレポジトリに公開もしています。 GitHub DEMO なお公開しているのはクライアントサイドのみで、サーバサイドの実装は公開していません。なお、エムスリー社内で使用してい

    Reactを使って本気でアンケートシステムをつくった - Qiita
    progrhyme
    progrhyme 2017/12/26
  • Ruby の NODE を GC から卒業させた - クックパッド開発者ブログ

    こんにちは、技術部のフルタイム Ruby コミッタの遠藤(@mametter)です。メリークリスマス。 Ruby 2.5.0 がリリース予定です。いろいろな改善が含まれています。クックパッドからの主な貢献としては、「trace 命令の削除による高速化」や「分岐・メソッドカバレッジの測定のサポート」などがあります。 ユーザから見える改善はいろいろと記事が出てくると思うので、この記事では、「抽象構文木のメモリ管理のリファクタリング」というあまりユーザから見えない改善を紹介してみます。 概要 Ruby のパーサは、NODE という内部的なオブジェクトで構成された抽象構文木を生成します。2.4 までの NODE は GC に管理される普通のオブジェクトでしたが、2.5 からは GC の外で管理するようになりました。これにより、3 つ嬉しいことがあります。 大きなコードのパースが速くなりました

    Ruby の NODE を GC から卒業させた - クックパッド開発者ブログ
    progrhyme
    progrhyme 2017/12/26