いまどきのインターネットは文脈文盲状態が当たり前 - シロクマの屑籠
1000リツイートを越えるとtwitterの闇が迫ってくる - シロクマの屑籠 上記リンク先の続きとして、いまどきのインターネットでは文脈が読み取りにくいことについて記しておく。 かつてのインターネット、ネットサーフィンするインターネットには文脈があった。それぞれのウェブサイトの構造がツリー状であったこと、ハイパーリンクをとおして他のウェブサイトへと繋がりあっていたおかげで、その書き手・その文章がどういう文脈に位置づけられているのかがハイパーリンクの次元で明らかになっていた。ネットサーフィンという行為、リンク集を辿る行為が、そのまま書き手の文脈を理解する助けになっていた。 ところがいまどきのインターネットは違う。ブログは記事単位で読まれ、グーグル検索などをとおして流入する人々の大半は書き手の文脈など調べるまでもなく、検索文字列と一致した情報の断片だけ持ち帰ろうとする。 このブログのトラフィ
ソシャゲエンジニアの自分が開発に必須だなと思った知識（MySQL編） - Qiita
この記事の目的 自分は、とある会社様の元でソシャゲの API 開発をさせていただいています。 ソシャゲは、リリース時やイベント時などに集中アクセスされやすく、負荷軽減の知識がない状態で開発を行ってしまうと、運用時に緊急メンテ祭りになりやすいジャンルかなと思っています。 これまで培ってきた MySQL の知識ですが、脳内メモリ量の関係上、暗記できないのでメモしておこうというのが主目的です。 ここ数年ほどソシャゲ開発しかしていないため、偏っている感がある内容ですのでご注意ください。 概要 ストレージエンジンは InnoDB。メインで扱っている MySQL バージョンは 5.6。 記事の内容ですが、これらのキーワードを見て、おおよそ分かる方は読む必要はないかと思います。 インデックス系 クラスタインデックス カバリングインデックス EXPLAIN で注意するべき値 トランザクション系 MVCC
（兎に角）早くプロトタイプを作る技術（初心者向け） - Qiita
とにかく早くプロダクトのプロトタイプを作るための技術についてまとめます。 この技術は運用しやすく作る技術とはまた別の技術です。 （綺麗に作るのは後でやる） かなり偏った考え方もあると思いますがご容赦ください。 プロトタイプを作る上でやらないことを決めます。 実はやることよりもやらないことを決めることの方が難しいです。 UXに基づいて後回しにするという意思決定が必要です。 プロトタイプでやるべきこと コンセプトの決定/チャネルの調査： なぜ作るのか、誰をターゲットとして作るのか、競合プロダクトの調査 コア機能の実装： ユーザの苦痛を解消させるプロダクトのコア機能の実装をします。 ここで想定しているコア機能とは一画面に収まるアプリケーションのメイン機能の事を指します。 デザインはモックレベルではなく、ユーザが使う想定のデザインテーマ、レイアウト、アフォーダンス、メンタルモデル、UI、アニメーシ
文科省のPython教材、改訂版が出ました！指摘に対して直したり直さなかったりと面白いです！ - パパ教員の戯れ言日記
5月に出た文科省の研修用教材に対して、micro:bitが出たぞ！やった！と浮かれていたら、修造botを完全に修造本人のTwitterとして紹介しているというデカいミスをやらかしているということを記事にしましたが、今回その改訂版が出ました。 blog.edunote.jp ちょっと見てみましょう。 改訂版はこちらから。 www.mext.go.jp ワードクラウドの紹介にはやはり修造は出てこなかった 前回更新後に訂正されたまま、走れメロスのワードクラウドでした。 では、他の場所はどうなったのでしょうか。 Qiitaで指摘されていた部分 Qiitaでは@nagataaaasさんが記事をまとめ、指摘していらっしゃいました。 qiita.com 私が見た感じ、この記事からは数点の修正が見られます。 以下、改訂前は http://www.mext.go.jp/component/a_menu/ed
ミスが全くない仕事を目標にすると、ミスが報告されなくなる『測りすぎ』
たとえば天下りマネージャーがやってきて、今度のプロジェクトでバグを撲滅すると言い出す。 そのため、バグを出したプログラマやベンダーはペナルティを課すと宣言する。そして、バグ管理簿を毎週チェックし始める。 すると、期待通りバグは出てこなくなる。代わりに「インシデント管理簿」が作成され、そこで不具合の解析や改修調整をするようになる。「バグ管理簿」に記載されるのは、ドキュメントの誤字脱字など無害なものになる。天下りの馬鹿マネージャーに出て行ってもらうまで。 天下りマネージャーが馬鹿なのは、なぜバグを管理するかを理解していないからだ。 なぜバグを管理するかというと、テストが想定通り進んでいて、品質を担保されているか測るためだ。沢山テストされてるならバグは出やすいし、熟知しているプログラマならバグは出にくい（反対に、テスト項目は消化しているのに、バグが出ないと、テストの品質を疑ってみる）。バグの出具
趣味でWebサービス作ったと思ったら、時が10年過ぎてた話｜yositosi｜note
本日、2019年9月24日で、私がTogetter（トゥギャッター）というサービスを作って丸10年になります。キリも良いし、私もnoteに何か書いてみたいと思っていたので、サービスの歴史などを書いていこうと思います。 トゥギャッター誕生Togetterというサービスは、名前からも想像できると思いますが、Twitter関連のサービスで、誰でも自由にツイートをまとめることができるサービスです。2009年当時の私は、個人の趣味でいろいろなWebサービスやアプリを開発して、リリースしては潰すということを繰り返してて、大体の作っているサービスの名称はダジャレで考えていたので、Togetter（トゥギャッター）も、ツイートをトゥギャザーする（一緒にする）という想いを込めて、Twitter＋Together=Togetter という形で安易に決まりました。まさか、このダジャレで考えたサービスに10年間フ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
