本当にDropboxはオンプレ回帰なのだろうか？

おはようございます。やっぱヒノキっぽいんだよなぁ、、、（花粉 ということで鼻ズルズルマンです。

Dropboxはオンプレ回帰した？

最近良く聞きます、Dropboxはオンプレ回帰した、クラウドはコストが高いから最近オンプレに戻る企業が増えている、とか。

一つ一つの記事やツイートをイチイチピックアップはしないですが、とにかくよく聞くわけです。

でも思うんですよね、「そんなわけないのでは？」だってよく考えてみてください、テックが強い組織であればあるほど適材適所でクラウドを使ったほうがいい所も見えてきます。 現代のアーキテクチャでクラウドがハマる部分が全くないシステムはありません。一時的なリソース確保と開放、管理のいらないインフラ、様々なサービス。これを利用しないなんてことあるのかな？ってことなわけです。無理にオンプレのみで頑張るのが論理的か？という話かもしれません

Dropboxがオンプレに移設したシステム"Magic Pocket"とは？

よくお話に出るオンプレ回帰の根拠はこれです。

dropbox.tech

このMagic Pocketと呼ばれているSMR（Shingled Magnetic Recording）を使用したストレージシステムにAmazon S3から置き換えたということです。 これはまずDropboxというサービスがストレージをお客さんに貸し出すサービスで、どうしてもストレージを大量にもつ必要があったから、そしてローカルストレージの共有サービスであるためにある程度低いレイテンシが求められたから、です。Dropboxはサービスを高速に拡張するためにS3バックエンドでサービスを開始しました。ですが、ストレージを大量にS3に置くことで問題が出ることは想像に難くはないわけです。まず、一番大きいのはストレージコストだと思います、データ保存自体の料金は必ずしも高いものではないと思いますが、リクエスト料金、そしてEgressのネットワークトラフィック料金については大量にかかるはずです。そしてパフォーマンスです、S3などのRestベースのアプリケーションのオーバーヘッドは通常のブロックデバイスのアクセスに比べるとレイテンシは大きいものとなり、細かいファイルへのアクセスがほとんどと思われるDropboxのオーバーヘッドは積もり積もって大きなものになっていたと想像します。加えてDropboxの人の言葉を借りると「ストレージを社内に持ち込むことで、スタック全体をエンドツーエンドでカスタマイズし、特定のユースケースのパフォーマンスを向上させることができます。」ということなので、各コンポーネントを近い場所に置くことができるとレイテンシに有利ということなのかと想像します。

これらの要件、更に安いギガバイトあたりのコスト、更に低いレイテンシ、達を解決するために恐らく僕らが想像するより大量の集約したオンプレミスと、その中に独自に作り込んだシステムがMagic Pocketなわけです。

dropbox.tech

Magic Pocketについて詳しくはこちらを見ていただければと思います。

じゃあDropboxはオンプレ回帰したのかというと、そうではなく、あくまで解決したかった問題を解決するための手段としてオンプレを選択しただけじゃないかなと思っています。

Dropboxはじゃあパブリッククラウドを使ってない？

Magic Pocketは2015年に稼働しはじめたわけですが、2020年にDropboxはこういった事例をだしています。

aws.amazon.com

34PBのデータレイクをオンプレミスのHadoopからS3上に移設した、という事例です。34PBのデータをS3にただ置くだけで年間いくら掛かるかというと、最適化しないと10億円以上かかります。実際はクラスタとか色々起動するのでそんなものではないと思いますが、ここから34PBは間借りするレベルではなく、これは必要であればクラウドもちゃんと使うよという意思を感じる量ですよね*1

そして次に2023年の記事です

dropbox.tech

これにも”the backend is a Hadoop cluster on top of Amazon Web Services (AWS). ”(バックエンドはAWS上のHadoopクラスタである）と書いてある記事があり、恐らく上記のクラスタであるということが言えるかなと思います。

また、この記事にも、 dropbox.tech

”The Dropbox platform runs on a hybrid cloud infrastructure that encompasses our data centers, global backbone, public cloud, and edge points-of-presence (POPs)”（Dropbox プラットフォームは、当社のデータセンター、グローバル バックボーン、パブリック クラウド、エッジ ポイント オブ プレゼンス（POP）を網羅するハイブリッド クラウド インフラストラクチャ上で実行されます）とありますのでパブリッククラウドとの接続はきちんと持っているようです。

追記

追記の情報もらったので追加

"Alki"というユーザのコールドメタデータを管理するシステムもDynamoDBとS3という構成でかなりキッチリAWSを利用する構成になっているようです。 個人的に2020年でこれ組んでるのめっちゃ熱い

dropbox.tech

www.youtube.com

オンプレ回帰ってなんだろう

ここまで色々見てきましたが、このようにDropboxさんが何をどこまで持っているかわからないですが、まず超大規模と言えるシステムがあり、その中で解決したい問題があり、そのための手段としてオンプレを選択している。ただ必要に応じてパブリッククラウドはもちろん使うという話でした。 要するに、これは単純な判断のなか高いからやっぱりクラウドやーめた！みたいな判断ではなく、まずDropboxという前提ありきの、オンプレ回帰というよりはもっと大きな組織の判断であって、一般的な潮流としてオンプレ回帰を狙うことは殆どにおいてないのではないかと思います。

もちろんクラウドの合う合わないユースケースはあると思います。人件費、データセンタコスト、ネットワークコスト、などなどを鑑みて一部オンプレ、みたいな判断はあると思います。ですが、全面的にクラウドを撤退するという判断は現段階において一般的な判断ではないというのは、システムをオンプレ上に構築し、運用するのにどれくらいのエンジニアが何をする必要があるか、エンジニアを雇う？他の会社にやってもらう？そしてアーキテクチャをきめ、HWの選定をし、購入し、構築をし、運用をします、壊れれば対応をし、改善し続ける、このコストを払うことのできる場合に行える選択だと思うからです。これはただクラウド高いからオンプレにもっていきました幸せ！というシンプルで簡単な話ではないと思います。

クラウドのコストが高いというのであれば何にコストがかかっているのかを明確に、パフォーマンスの課題があるならどこに課題があるのか明確にして、それを解決する手段として何を取るのか、みたいな所から判断をしていくことができるはずです。そしてそれは”オンプレ回帰”でというバズワードのようなものではなく”適材適所の選択”であるべきだと感じました。

適当に書いてみましたが、みなさんの良いクラウド？オンプレ？生活の一助となれば幸いです！ ではでは！

*1:EBと比べれば小さいというのはわかりますがｗ

DBRXでもコーディング性能を比較してみた

liginc.co.jp

こちらのBlogを見て、DatabricksのLLMであるDBRXだとどんなもんかなーと思って試してみました！ いけんのか？

コード生成のテスト

まず、こちらのコード生成ですが、画像をまだ認識することはできないため、こんな感じのプロンプトで生成させてみました。

Please create a UI/UX login code, using Next.js and Tailwind. Please make elements that Email, Password Login button. Next.jsとTailwindを使って、UI/UXログインコードを作成してください。メール、パスワードログインボタンの要素を作成してください。

import React from 'react';

const Login = () => {
  return (
    <div className="flex items-center justify-center h-screen">
      <div className="w-full max-w-md">
        <form className="bg-white shadow-md rounded px-8 pt-6 pb-8 mb-4">
          <h2 className="text-2xl font-bold mb-4 text-center">Login</h2>
          <div className="mb-4">
            <label htmlFor="email" className="block text-gray-700 text-sm font-bold mb-2">Email</label>
            <input
              type="email"
              id="email"
              className="shadow appearance-none border rounded w-full py-2 px-3 text-gray-700 leading-tight focus:outline-none focus:shadow-outline"
              placeholder="Email"
            />
          </div>
          <div className="mb-6">
            <label htmlFor="password" className="block text-gray-700 text-sm font-bold mb-2">Password</label>
            <input
              type="password"
              id="password"
              className="shadow appearance-none border rounded w-full py-2 px-3 text-gray-700 mb-3 leading-tight focus:outline-none focus:shadow-outline"
              placeholder="**********"
            />
          </div>
          <div className="flex items-center justify-between">
            <button
              type="submit"
              className="bg-blue-500 hover:bg-blue-700 text-white font-bold py-2 px-4 rounded focus:outline-none focus:shadow-outline"
            >
              Login
            </button>
            <a href="#" className="inline-block align-baseline font-bold text-sm text-blue-500 hover:text-blue-800">
              Forgot Password?
            </a>
          </div>
        </form>
      </div>
    </div>
  );
};

export default Login;

残念ながらデザインは無いですが、ログインページのようなものを生成してくれました。

バグ解決のテスト

次はバグ修正のテストです、以下のプロンプトで修正をお願いしてみました。

使用した⁠プロンプト Pythonを使用しており、このコードで問題に直面しています。売上の総額が最も高い月を正確に特定したいのですが、売上データが空である場合のエッジケースの処理にも対応したいです。この問題を解決してください。

サンプルデータ
"
(1, 'January', 200),
(2, 'January', 150),
(3, 'February', 300),
(4, 'February', 250),
(5, 'March', 100),
(6, 'March', 150)
"

コード
”
def find_highest_sales_month_corrected(sales_data):
    if not sales_data:
        return "No sales data available", 0

    totals = monthly_sales_total(sales_data)
    if not totals:
        return "No valid sales data", 0

    highest_month = max(totals, key=totals.get)
    return highest_month, totals[highest_month]

highest_sales_corrected = find_highest_sales_month_corrected(example_sales_data)
highest_sales_corrected

empty_sales_data = []
highest_sales_empty = find_highest_sales_month_corrected(empty_sales_data)
highest_sales_empty
”

生成結果は以下の通り

おそらく、monthly_sales_total 関数が定義されていないためにエラーが発生していると思われます。以下のように monthly_sales_total 関数を定義して、月別の売上総額を計算することで問題を解決できます。

def monthly_sales_total(sales_data):
    totals = {}
    for sale in sales_data:
        month = sale[1]
        total = sale[2]
        if month not in totals:
            totals[month] = 0
        totals[month] += total
    return totals

def find_highest_sales_month_corrected(sales_data):
    if not sales_data:
        return "No sales data available", 0

    totals = monthly_sales_total(sales_data)
    if not totals:
        return "No valid sales data", 0

    highest_month = max(totals, key=totals.get)
    return highest_month, totals[highest_month]

example_sales_data = [(1, 'January', 200), (2, 'January', 150), (3, 'February', 300), (4, 'February', 250), (5, 'March', 100), (6, 'March', 150)]
highest_sales_corrected = find_highest_sales_month_corrected(example_sales_data)
print(highest_sales_corrected)

empty_sales_data = []
highest_sales_empty = find_highest_sales_month_corrected(empty_sales_data)
print(highest_sales_empty)

この修正により、空の売上データの場合には "No sales data available" と表示され、有効な売上データがある場合には最も売上の高い月を正確に特定することができます。

こちらは見事に修正することができました。

こんな感じでDBRXもコードの生成に使えることがわかりました！

2023年の振り返り

年の瀬ですね！（そうですね！）

今年は職を変わるという大分転機な1年だったので振り返りをざっと書いていこうと思います。

転職をした

AWSでやってたことも整理

新しい会社の前にAWSでやってたことも整理しておくと、以下の通り今までAWSでやってきた事はこんな感じで、

• お客様とお話するいわゆるソリューションアーキテクト
• Amazon DocumentDB を専門にするスペシャリストソリューションアーキテクト

をやってきた。 前者を6年くらいやってきて、そこからキャリアをどうしようかという試行錯誤の一つでAmazon DocumentDBのスペシャリストソリューションアーキテクトになった。というのが流れだと思う。どちらも非常に興味深いし面白い事ができたので良かった。

まず、ソリューションアーキテクトとして、お客様と、ある技術テーマにおいて効率よくAWSを使っていただくためにどうすればいいかをディスカッションするのはとてもエキサイティングだったけど、キャリアとして広げるためにやることかえてみっぺ。がスペシャリストソリューションアーキテクトという結果だったわけだと思う。

やはり、サービスを主体とするスペシャリストソリューションアーキテクトはソリューションアーキテクトとは動き方も目指すゴールも違っていて、ただ、やらないとわからないことも多いので、多分やってよかったと思っている。スペシャリストソリューションアーキテクトもそれはそれで楽しかった。

加えてレポートラインがシアトルの方だったり、シンガポールの方だったりというのを経験できたのも良かった。ぼくは力及ばずという所だったけど、英語をやらなければ、、、というモチベーションにもなったし、開発の人ととても近い位置で仕事ができたのでより本当のAWSを感じることができたんじゃないかなと思っている。

転職を考える

てか今年のはじめの時点では自分が転職してるなんて夢にも思ってなかった。完全にAWSでバリバリやってると思ってた。

それくらいAWSでの仕事は魅力的だったし楽しかったと思っている。

ただ中頃から挑戦したいなと思うようになったのも事実で、理由として2015年にAWSにはいった時のアーリーな感じをもう一回やってみたくなったというのが大きい気がする。今のAWSが悪いって思っているわけではないけど、あの頃の状況を繰り返すことはAWSにいるだけだとできないんじゃないかなと思った。*1

後は何をやるか、で、ソリューションアーキテクトをもう一回やってみたくなったのもある、お客様とお話して課題解決を行うというのがやはり自分は好きだったのを思い出したからだ。

なので、ちょっとアーリーな会社でソリューションアーキテクトができる所を探して話をきいてみたりしていた、何社かお話を聞かせていただいていたけど、その中の一社がDatabricks だった。

そして前のエントリにもちょっと書いたけど、自分が納得できるプロダクトがある所という条件もあり、Databricksはまさにステージもそうだし、プロダクトも興味がある、そうかーじゃあ楽しいかもしれないねってなったのが大きかった。

転職

あれよあれよとプロセスは進んで、オファーいただくことができた。

英語の面接もあったけど、Zoomのおかげもあってｗ なんとか話することができた。ただ多分今の上司が外国の方じゃなかったら今頃このレベル（マジでたいしたレベルではないけど😓）では会話できてないよな、、、って思うといろんなものは無駄じゃなくてつながってるんだろうなって思った。*2

で、その間にお休みいただいてゆっくりやすんだりTwitterではっちゃけたりしてる*3間に入社日になったというわけですｗ

今日からリブート！！！
DatabricksさんでSolutions Architectとしてお世話になります！
(PCと格闘していた) pic.twitter.com/JZbbIRkLs9

— akuwano (@kuwa_tw) 2023年10月23日

この後どう転がるかはわからないけどこういうものは後で答え合わせしないとあのときの選択がどうだったかなんてわからないので、自分は自分がなにかを選択したことを評価したいと思う。

2ヶ月たってオンボーディングも終わりかけ、2024年からはいろいろやれることを増やしていける感じになりつつあるので来年からお話する機会や、勉強会、それ以外でも活動増やしていければと思うのでよろしくお願いします！！！！

*1:実際の所そういう場所もあるのかもしれないけど

*2:ゆっくりしゃべる人なんで大丈夫ですよって言われて面接入ったら全然早口だったのだけはマジで忘れないとおもうｗ

*3:転職のタイミングでTwitterをちゃんと再開したけど大分世界が変わっていて難しいｗ

僕の理解するデータレイクハウスとはなにか？

こちらの記事はDatabricks Advent Calendar 2023の23日目の記事です！

何年ぶりにかくねん、、、8年ぶり！！！！！？？？？
嘘やろ、、、、😨

という衝撃はおいておいて、8年ぶりともなると色々変わっているわけで、一番大きいのは僕は会社をAmazon Web Services JapanからDatabricks Japanに変わりました。
転職の理由というのはポジティブな理由もネガティブな理由もあると思いますが、そういう細かいことはおいておいて（おくんかい）決め手になったのはこれです。

「Databricksというサービスに技術的なアドバンテージを感じたから」

SAとしていえばこういえるかもしれません、

「SAとして働いてる自分を想像して、Databricksをお客さまにオススメするときのイメージが付いたから」

でもあります。 とにもかくにもDatabricksというサービスが気になった、というのが転職理由の大きな理由の一つなわけです。 そこでみなさんはこう思うと思うんですよね「Databricksの何がいいの？」と。

今日はそれを（僕の理解の中の）めちゃくちゃザックリな説明をしていくというDatabricksってなに？という人向けの記事にしていきたいと思います。

それでは、行ってみましょう！ 絵が下手すぎて全くイメージ伝わらない、、、気がしてきた、、、けど考えるな感じろでお願いしますｗ

Databricksって何だ？

まずDatabricksってなんなんでしょう、、、？
よく言われるのはマネージドApache Sparkだとか、ですがそれはDatabricksの一つの側面にしか過ぎないと思うんですよね？
Databricksはこう言ってます、データレイクハウスと、、、何やそれ、という方に最初からお話していきましょう、、、。

データウェアハウスの誕生

データ分析をするにあたって、みんなは思いました

「メチャクチャなデータ量のデータに対してもちゃんと応答できるデータベースをつくればいいじゃない」

それをみんなはデータウェアハウス（DWH）と呼ぶことにしました。

DWHは非常に重宝されましたが、そのうち問題が出てきました。

「構造化データはデータベースに入れやすいけど、動画や、音声などの非構造化データはどうやって分析する？」
「データの管理場所がバラバラになって管理しづらいよ」
「データを入れたらめちゃくちゃお金かかるよ」

みんなは困ってしまいます。

データレイクへ

そこでみんなは考えました。

「そうだ！データを統一したいれる場所を作ってそこから使いたいときは引っぱり出してくればいいんだよ」
「データの泉、、、データレイクだ！」

みんなはデータレイクにいろんなデータをとにかくドンドン入れていくようになりました。 データレイクは非常に安く、データレイクに入ったデータをみんなは、データの分析や、機械学習に使っていきます。

あれあれ、、、でもそのうちにまた誰かが困っているようです。

「とにかく入れまくっていたからデータレイクがぐちゃぐちゃだよ」
「このデータって正しいデータなのかな、、、？」
「データレイクからデータとってくるのちょっと遅くない？」

これでは泉ではなくて沼です。やっぱり困ってしまいました。*1

そしてデータレイクハウスへ

そのうちまた誰かが言いました。

「データレイクの中でデータウェアハウスがうごかせれば全部解決するんじゃないの？」
「それだそれだ！」
「でもどうやって？」
「データレイクの上でトランザクションや、スキーマを設計することができればそのまま動かせるよ」
「いいね！やってみよう！」
「でも名前がないと分かりづらいな、、、データレイクとデータウェアハウスを合わせてデータレイクハウスって呼ぼう」

こうしてデータレイクハウスという概念が生まれました。 データレイクハウスは低コストなクラウドストレージの上にオープンファイルフォーマットと言われる特別なフォーマット*2で、トランザクションやスキーマの強制、パフォーマンスの強化を実現しました。 それによってデータウェアハウスの課題であった、データの分断やコスト、データレイクでの課題であった課題（データ品質、パフォーマンスなど）も解決することとなりました。

要するに、 ”データレイクと、データウェアハウスのいいところどり、データの格納場所はデータレイクなので、安価かつオープン。構造化データも非構造化データも取り扱える。しかもデータガバナンスが効かせられ、処理も高速。データ分析にも、機械学習にもオールインワンで活用可能” というのがデータレイクハウスの良さになるわけです。

Databricksの何がいいの？の第一歩がレイクハウス！

これがDatabricksがよくお話するデータレイクハウスのザックリとしたお話でした。なんか夢があっていいですよね。でもこれは現実です😆

データレイクハウスを最初に始めたというだけではなく、それをドンドン進化させ続けているのがDatabricksというプロダクトというわけです。

閑話休題：Databricksってどんな会社？

ここでちょっとDatabricksという会社についてお話しようと思います。
まだ入って二ヶ月ですが、まず言えるのが非常にみなさんスキルフルという点、技術が好きな方が多くて、技術ディスカッションなどになると白熱していることもあって楽しいです。
なおかつ、非常に研修なども豊富ですごい大変ですが、ためになるコンテンツがたくさん揃っています。
アットホームで楽しく仕事をできる*3環境もあるので是非Databricksにもっと深く触ってみたい！という方はお声がけください！採用強化中です！ｗ

[PR][定期ポスト]
Databricks は採用強化中です! 営業、各種ソリューションアーキテクト、有償コンサル等!
納得できるプロダクトに関わりたいと言う方、ピッタリです😃
Databricksちょっと気になるけどよく分からん!という方はお気軽にお声がけくださいませ!
[PRココマデ]https://t.co/5b4XOXDZUi

— akuwano (@kuwa_tw) 2023年12月1日

Databricksのお気に入りのサービス

ほら、、、AWSでもよく好きなサービスっていってたから、、、😅
DatabricksでいうとUnity Catalogが大好きです！！！
データカタログのサービスではありますが、単なるデータカタログというだけではなく、統一した権限管理／アクセスコントロール、監査ログ、データの依存管理（データリネージュ）、機械学習のモデルレジストリなど様々な機能を持ったサービスとなっており、Unity CatalogがあることでDatabricksはより統一されたガバナンスを効かせることができます。
最近の新しい機能にもUnity Catalogは深く結びついていて、ただのマネージドhive metastoreでしょ？と思っているとぜんぜん違うのできっとビビります！

まとめ

そんなこんなでとりあえず最初に面白そうと思ってもらえる記事を目指して書いてみましたがいかがでしょうか？ Databricks自体は聞いたことあるけどどんなものかよくわかってないという方はまだまだいる気がしているのでこういう記事もまた書いていきたいと思います！

*1:ちゃんと運用されてるまさにデータレイク、というものもあるので絶対にこうなる、というわけではないですが課題の一例としてお聞きください

*2:Databricks で使われているのはDelta Lakeといいます

*3:メタファーの奴じゃないですｗ

子供と一緒にカレーが食べたい

※このエントリは個人の見解であり、所属する組織の公式見解ではありません 今年も何故か完全にすっぽかしてしまうというアレをしてしまうアレ(´；ω；｀)

このエントリは、カレー Advent Calendar 2016 19日目のエントリです。 19日目、、、。

またや、、、また人権が失われました。

某Slackのチャンネルで、 @kuwa_tw が学習しない野郎として晒されている... and @la_luna_azul の優しさを見ている。

— Y.Namikawa / id:rx7 (@namikawa) 2016年12月20日

悲しいですね。人は繰り返してしまう生き物。

子供と一緒にカレーが食べたい

子供と一緒に御飯を食べていますが、まだ本格的なカレーは食べられないわけです。 ただ一緒に食べたいという気持ちはあるわけです。 じゃあどんなものがあるのか、それですね。

とりあえずなんでも食べてくれてた時代

離乳食の頃にはだいたいなんでも食べてくれていてありがたかったです。

和光堂 BIGサイズのグーグーキッチン ごろごろ野菜のキーマカレー 100g

とか

和光堂 グーグーキッチンBIG ハンバーグカレー 100g×6個

を食べてくれてましたね。「ｶﾚｪ」

S&B カレーの王子さま 顆粒 60g×4個

いわゆるカレーの王子さまもたべてくれました。

大きくなってきて通用しなくなる時代

いわゆるイヤイヤ期にはいると、大人と同じものが食べたくなってきます。そうするとこうなるわけです。 「カレーない！（コレじゃない！これは色がお父さんが食べてるやつと違う！）」

そう、、、なんか色が薄いんすわ。自分が見ても「まあ違うものに見えるわな」となりますものね、、、。

というところで色々見ていった結果アンパンマンカレーが一番色が濃いし1歳から食べられるのでベスト。結構美味しい。ということがわかりました。

永谷園 アンパンマンミニパックカレー ポークあまくち 100g(50g×2)×10個

息子もニッコリですわ。

というわけで。

子供と一緒にカレーライフ楽しみましょう！！！

ちな

最近食べたので一番美味しかったのは「ボーイズカレー」の生姜焼き定食（カレー付き）で、こんなに美味しい生姜焼きはこの世にないです、、、アレ、、、？ カレーもありますっす！

可愛い見た目のSlack入門 [ChatOpsによるチーム開発の効率化]中身も可愛い奴だぜ

※このエントリは個人の見解であり、所属する組織の公式見解ではありません

前職からのお付き合いの @matsukaz さんに

Slack入門を頂きました！ありがとうございます！

ちゅーわけで早速読んでみたりします。 一言で言えばSlackの使い方についてまとめた本、なんですが、そこはそれ、いわゆる本屋さんにあるHow to本（で○るシリーズとか）ではないわけです。 チームの作り方、アカウントの作り方、それを既に使っている方々は知りたいですか！？ あ、、、いやもちろんそれもありますｗ もちろんSlackの使い方は細かい所、そんな使い方あったんだ、、、と言うところまでかいてあるんですが実際に開発の現場でSlackの使っている人が知りたい

• SlackのAPI活用方法
• SlackでChatOpsを実践するための方法や実例
  • Hubotの細かい仕組みや構築方法、実践方法
• GithubやCircleCIとの連携方法

といったやり方が具体的に載っている本なわけです。 おもしろBotが作りたい方、開発にもっとSlackを活用したい方、無料枠で使ってるみたけどホントにSlackって便利なのかな、、、Skypeで良くね、、、俺、、、ミーハーなのかな、、、鬱だ氏のうって内心おもってる方は一度読んでみるとSlackである必要性、というのがわかるかもしれません！

最近我が家の家庭のやり取りもLINEからSlackになりつつある今日このごろですがこれを期にもっとSlack活用したいと思います！

絶対できる! 【スラックライン入門】 〜トッププロが教える16テクニック〜 [DVD]

Slack入門 [ChatOpsによるチーム開発の効率化]

心機一転

はてなブログに移行した Markdownは楽だは。