mala

Smoozサービス終了に寄せて

前置き

• この文章と、それに含まれる考察や各サービスへの脆弱性報告などはmala個人の活動であり、所属している企業とは関係ありません。
• 一方で私は、企業が閲覧履歴を収集して何をしたいのか、所属してる企業や他社事例について、ある程度詳しい当事者でもあります。
• 一般論として書けることは書けるが、(業務上知り得た知識で開示されてないものなど)個別具体的なことは書けないこともあり、また観測範囲に偏りがある可能性もあります。

Smoozに報告した脆弱性2件

eiel

<?php

namespace RadioControllerCar;

/* ラジコンの抽象クラス */

interface CarInterface
{
    public function send($message);
}

shizone

勉強会名	主催者・運営者	URL	直近一年での開催
Okayama.rb	@ore_public @mako_wis	https://okaruby.connpass.com	あり
okayama-js	@maepon	https://okayama-js.connpass.com/	なし
岡山Javaユーザー会	@zephiransas @razon @ryosms	https://okajug.doorkeeper.jp	あり
中国地方DB勉強会（岡山）	@ikkitang @razon @mako_wis	https://dbstudychugoku.github.io/	あり
リーダブルな夜	@SawadaStdDesign @maepon @sakie_boondock @mako_wis	https://readable-na.connpass.com	あり
Okayama Managers Meeting	@mao_instantlife	https://omm.connpass.com	あり
岡山Python勉強会	@yamayama_k5	https://okapython.connpass.com/	あり
JBUG岡山	@mao_instantlife	https://jbug.connpass.com/	あり

joepie91

Getting confused about the piles of development tools that people use for Javascript? Here's a quick index of what is used for what.

Keep in mind that you shouldn't add tools to your workflow for the sake of it. While you'll see many production systems using a wide range of tools, these tools are typically used because they solved a concrete problem for the developers working on it. You should not add tools to your project unless you have a concrete problem that they can solve; none of the tools here are required.

Start with nothing, and add tools as needed. This will keep you from getting lost in an incomprehensible pile of tooling.

Build/task runners

Typical examples: Gulp, Grunt

kawasima

アーキテクチャ大全のサンプル

これくらいの実例とともにソリューション選択できるようにしていきたい。

kawasima

アーキテクチャ設計のドキュメンテーション

コンテキスト

アジャイルプロジェクトのアーキテクチャは、別々に記述され定義されなければなりません。すべての意思決定が一度にされるわけでもなく、プロジェクト開始時にすべての意思決定がされてるわけでもありません。

アジャイル手法では、ドキュメンテーションに反対はしませんが、価値のないドキュメンテーションはいけません。チーム自身の助けになるようなドキュメントは価値がありますが、ちゃんと最新化し続けなければなりません。膨大なドキュメントでは、最新化されなくなることでしょう。小さくまとまりのあるドキュメントは少なくとも更新される可能性はありますよね。

また膨大なドキュメントはだれも読みません。たいていの開発者はソースコードサイズの合計よりも(byte的な意味で)大きな仕様書が書かれたプロジェクトを少なくとも1回は経験したことがあるでしょう。開くのにも、読むのにも、更新するのにも、そんなドキュメントは大きすぎます。一口大のピースに分解すれば、すべての関係者にとって消化するのは簡単になりますよね。

プロジェクトが動いている間、追跡するのが難しいことの1つに、ある意思決定の裏に隠された「思い」があります。プロジェクトに新しく参画した人は、それまでに決定されたことに困惑したり、戸惑ったり、喜んだり、怒ったりすることでしょう。理念や因果関係を理解しておかないと、その人は次の2つの選択をすることになります。