技術書というのが 「ソフトウェア/インフラエンジニアが読むフレームワークや言語についての本」 だと仮定すると、 高度な内容になればなるほど、読者とニーズが減るので、入門者向けの内容になりがち 入門者向けの内容であれば、フレームワークや言語の公式サイトにあるGetting Startedのドキュメント（英語）で必要十分 その内容は、トップレベルのエンジニア集団が自分たちの技術の普及を賭けて練り上げたもの（のはず）なので、クオリティはだいたい高い 逆に言うと、それが貧弱だったりわかりにくかったりする技術は信頼性に欠くので、あまり学ばないほうが良さそう、本気度からくる将来性が低そう 英語ドキュメントに抵抗が少ないエンジニアは最初から公式サイトの1次情報を見て学習し、足りない情報は英語のブログや動画から勝手に補完していく 1~3から、英語が苦手なエンジニアが入門時に読む感じの本が多く出版される。

2021年3月、FastHnadle2として、作り直しました。 https://github.com/kuritaka/fasthandle2 Python Fabricを使うのではなく、fhコマンドを自作しています。 #FastHandleとは FastHandleは、サーバ構築、サーバテストのオペレーションをサポートするツールです。 サーバ構築をより早く、より正確にすることを目指して作っています。 自動化のために、Fabricコマンド、Expectコマンドなどを利用しています。 現状、こんな感じにしようという枠組みはできましたが、まだまだ作成途中です。動かないこともあると思いますが、少しずつ増やして、テストをしていきます。(2018/01/11) 今はLinuxサーバ向けですが、Windowsサーバも検討していきたいと考えています。(2018/01/11) WindowsやVMware

はじめに クラスメソッド株式会社 AWS事業部長の佐々木です。 私は前職で創業メンバーの1人としてビジネスを立ち上げた後、エンジニアとして実業務に携わりながら、統括マネージャーとして50人規模のエンジニア組織を構築しました。 また2014年にAWSエンジニアとしてクラスメソッドに入社し、2015年7月よりAWS事業部の部長に就任。事業は順調に拡大しており、2015年と比較して組織も2倍以上に大きくなりました。これは優秀な仲間に恵まれたのはもちろんのこと、組織設計と構築プランが功を奏したことも一因だと感じています。 そこで、私がこれまでに培ってきた経験から得たエンジニア組織の構築の仕方をお伝えしたいと思います。 エンジニア組織構築マニュアル 骨子を定義する これはエンジニア組織に限りませんが、組織には3つの骨子が必要です。 ポリシー ビジョン ターゲット ポリシーは、その組織が最もこだわる一

You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert

私は、未解決の問題があると夜眠れないような人間だ。このことに気づいたのは、学校での算数の授業でのことだった。また幼い頃、特定の角度でひねることによって解体できる金属ワイヤーパズルを手にするたびに、これを思い知らされた。 大学で数学を専攻した私は、卒業後にソフトウエアエンジニアとして、必要であれば徹夜で問題解決に取り組んだ。コンサルタントになってからも、ビジネス課題の問題解決をしていたが、非常にひねりがあって複雑な問題が多かった。 私は問題解決能力がいくら向上しても、いまだに「プロセス」に注意を払い続けている。というよりも、私が問題解決に長けている理由は間違いなく、規律あるプロセスを使用していることにある。 特に他者と協働するとき、効果的に問題を解決したい場合には、規律あるプロセスを踏むことが非常に有効だ。私が考案した「SPOT」の4ステップに従えば、時間が節約でき、何も解決できない見せかけ

「うーん、だいたいWebサーバは、vCPU2で、メモリ8GBぐらいで良いんだけれど、どのインスタンスが一番お得なんだろう？　よくわかんねぇ・・・(;´Д｀)」 現在、EC2インスタンスは現行世代だけでもタイプが１８種類。旧世代も合わせて、全ての世代・サイズを合わせると、その種類は100を超えます。 それぞれのユースケースを想定して多数のインスタンスタイプが用意されているわけなので、EC2の進化には驚くものがあるのですが、最初に軽くインスタンスを選ぼうと思っても、種類が多すぎて選ぶ時の敷居が高くなっているかなぁと感じるときもあります。 今日は、そんなインスタンスタイプの選択に迷っている方に向けて、EC2インスタンスの比較検討が、非常に効率的にできるサイトを紹介します。あと、インスタンスタイプ比較検討マニアにも受けるかもね！ ほな、行ってみよ。 サイト「EC2Instances.info」の紹

Redash？ RedashとはさまざまなデータソースからSQLなどのクエリを駆使してデータを取り出し、グラフやレポートをGUIで作ることのできるオープンソースのツールです。 Webエンジニアをされていれば、いい感じにデータを抽出してほしいという依頼が飛んできたりすることもあるのではないでしょうか？ Redashでは実行したクエリを保存して別の人が違うタイミングで実行したり、ダッシュボードにまとめてレポートを作ったりすることができるので、その辺の要求に簡単に応えられるようになるのではないかと思います。 Redashハンズオン？ この記事のタイトルにもありますRedashハンズオンはid:kakku22 さんが作られているもので、ハンズオン中で使うデータを含め環境構築まですべてが書かれています。 MacでもWindowsでも問題なくできるそうなのでこれも嬉しいなと思いました。 動機 どのくら

当社はCookieを使用して、お客様が当社のWebサイトでより良い体験を得られるようにしています。引き続き閲覧する場合は、プライバシーポリシーに同意したことになります。

import { app } from "hyperapp" import { div, h1, button } from "@hyperapp/html" const state = { count: 0 } const actions = { down: value => state => ({ count: state.count - value }), up: value => state => ({ count: state.count + value }) } const view = (state, actions) => div([ h1(state.count), button({ onclick: () => actions.down(1) }, "–"), button({ onclick: () => actions.up(1) }, "+") ]) const

それはもう「テキストエディタ」と別物といっていい。価格は3000円。書き手の目線、余白、グリッド…細部にこだわり、無駄を排除。『stone』は書く心地よさのみを追求し、App Storeでも1位*を獲得した。つくったのは日本デザインセンターの面々。あらゆるプロダクトに活きる、心地よさのデザインとは？ (*)... 2017年12月2週目時点 心地よさにこだわり抜いたエディタ「stone」 日本を代表するグラフィックデザイナー、原研哉さん率いる日本デザインセンター（NDC）が、とてもユニークな自社プロダクトをリリースした。それが『stone』だ。 広義でいえばテキストエディタの類だが、あまりにもシンプルなつくり。アプリを起動し、映し出されるのは真っ白な画面。言われなければエディタだとわからないかもしれない。 「僕らが意識したのは、触感であったり、気持ちよさなんです」 今回お話を伺ったのは、企

こんにちは。カヤックのSPAおじさんこと島津です。 今年はReactとVueを使ったSPA開発プロジェクトをいくつか担当してきたので、そこで得た知見の総まとめをしたいと思います。 ※ ここでのSPAとはすべてのViewをJavaScriptで書くWebアプリのことを指します。サーバーサイドMVCを主軸にViewの一部をReactやVueで書くこともありますが、今回はそのケースではありません。 1. フレームワーク 数年前とは事情が変わり、 フレームワークを使わないという選択肢は昨今だともう無いでしょう。丸腰のJSでDOMを弄っていた時代に比べると、かなり安定したフロントエンドの開発ができるようになりました。 人気フレームワークの台頭になっている React + Redux Vue + Vuex をこの1年使ってきましたが、書き方は違えどFluxアーキテクチャ・仮想DOM・コンポーネント志向

旅先ではいつも、その土地のものを食べるのが習慣だ。だが、ときおり、外国で日本料理屋に入ることもある。そして、たまに面食らうような体験もする。いつだったか、アメリカの日本料理屋で食事を頼んだら、まっさきに味噌汁だけが出てきた。ふつうの街にある店で、来客はアメリカ人が多い。どうやら彼らの概念では、味噌汁はスープだから（Miso soupとよばれる）、真っ先に出すのが当然だということらしい。味噌汁を飲み終えたら、メインのおかずとご飯が出てきて、妙な気分だった。 汁物をsoupと訳するのは、もちろん正しい訳だ。だが日本語で言う汁物と、英語のスープは微妙に違う。たとえば英語では、スープは食べる（eat）という。日本人で、「味噌汁を食べる」という人は滅多にいるまい。ふつうは飲む、を使う。そして、当たり前だが、ご飯と一緒にいただくものだ。

はじめに こんにちは、@tsuwatchです。普段はRubyを書くのですが、仕事の幅も広がりつつあり、フロントエンドも本格的にやっていこうということで、 Kaizokuというニコニコ生放送のデスクトップアプリをリリースしました。 人生の大半の時間がニコ生に溶けているわけですが、かねてからコメントビューワを作ろうと思っていたので、この機会に作ってみました。 しかし、Mac版のコメントビューワにはHakumaiという大変素晴らしいコメントビューワが存在するので、少し違う方向を向いた生放送ビューワをかねたアプリにしました。 Hakumaiはコメントビューワとしては数少ないオープンソースなので、実装やコメントサーバの仕様など大変参考にさせて頂きました。この場をお借りして、お礼を申し上げます。 アプリの機能や今後についての紹介はまた別途ブログで書くと思います。 ご興味がありましたら、ぜひ使ってみてい

本記事では、 チームによる持続的に変更可能なWebアプリケーションの開発を目標に、フレームワーク導入時に考慮すべき22の観点を紹介する。 フレームワークによって特徴は異なるが、本番導入にあたって、考慮すべきポイントはあまり変わらないので、極力フレームワーク1に依存しすぎないよう配慮する。また、話をシンプルにするため、REST APIを提供するアプリケーションを題材とする。 前提 ソフトウェアのエントロピー ソフトウェアがエントロピー増大の法則を避けられないことを、体感している開発者は多いだろう2。普通にアプリケーション開発を続けると、開発スピードは鈍化し、品質は低下してバグが増え、開発者からは技術的負債への怨嗟の声が聞かれるようになる。エントロピー増大というフォースは極めて強力で、意思を持って立ち向かわなければ、容易にダークサイドに堕ちてしまう。 関心事の分離 大規模Webアプリケーション

Visual Studio Code Advent Calendar 2017 の 11日目の記事です。 🙂 今年の自分は Java と PHP と JavaScript と電子工作の年だったような気がするのですが、そんな中、全てにおいて随分お世話になりました VS Code。Microsoft から Arduino 拡張がリリースされたのが一番驚きました。 ということで、今日より 3日間 VS Code について書いていこうと思います。まず最初は Language Support for Java(TM) by Red Hat（vscode-java） から。「フロントエンド技術を導入した Java ウェブアプリケーション開発」です。 この記事では VS Code で Java とフロントエンド系の開発を行うサンプルプロジェクトを準備しました。 簡単な操作で昨今のフロントエンド技術を使

同僚から「Spring Bootのこと教えてー」って声かけてもらったので、社内勉強会でこぢんまりと喋ってきた。 Spring Bootのコンセプト Springがコードレベルの、Spring Bootがアプリレベルの、Spring Cloudがサービスレベルの、みんながやることやっとくよ。な感じ。 ってつぶやいたらまきさんから @bufferings そういう話を非技術系の人によくしています。この図使ってますhttps://t.co/4RyLJzo1JS— Toshiaki Maki (@making) 2017年3月1日 って教えてもらったのでスライドを紹介しときました！あざます！ Spring Bootでおさえておくべき3つのこと 最初はどこまでがSpringでどこからがSpring Bootなのか分かってなくて「めっちゃ色々あって魔法みたいでよく分かんない・・・(ヽ´ω`)」ってなっ