Viewing entries in
AdventCalendar2015

23歳で前厄になるのでお参りしてきた

23歳で前厄になるのでお参りしてきた

僕の名前は山本真平。出身は北海道。公立はこだて未来大学を今年卒業して、晴れて4月からアットウェアで働き始めた。大学のころまで「ヤマ」などと呼ばれていたが、いろいろあって関東では「マッサン」と呼ばれている。そして名乗っている。案外気に入っている。

今日12月24日は弊社、アットウェアの創立記念日であり、アドベントの最後の日である。世の中はアドベントの最後の日、つまりクリスマスイブだというのに、僕らはいつも通り働いている。創立記念日というものは、社員みんなでパーティー的な催しがあるものだと思っていた。今の所、僕のカレンダーにそのような予定はない。

さて、1993年生まれ酉年の僕らは前厄になるのだから、何かしらの厄をどうにかするため、お参りしなければならない。よくよく考えてみれば、「お参り」ではなく、「お祓い」という言葉が適切だろう。どちらにしろ、ベトナム人の同期に、この違いを説明しなければならないと思うと少し億劫である。お墓を蹴っちゃいけないくらいの宗教観しか持っていない僕は、「厄年」というものがそもそもなにか気になって検索した。インターネットとは便利なものである。

厄年というのは、陰陽道で教育、宣伝されているもので、その年齢になると厄災が降りかかるとされています。平安時代には、すでに厄年という概念があり、現在まで長いこと受け継がれてきている風習です。
— yakuyear.com/about/what.html

そういうことか、いや、意味がわからない。なぜその年になると厄災が降りかかりますということが決まっているのか、そもそも厄災とはなんなのか、降りかかるものか、いろいろ突っ込みどころはあるが、「災い」という漢字が入っている以上、良くないことが起きることらしい。ある年に生まれた子供たちが、皆同じタイミングに災いが起きるなどというのは悲しすぎる。悲しい風習だということはわかった。

厄年を民俗学的に見ると、『役年』になります。ある一定の年齢になると、神社やお寺で『役』をするという習慣からです。『役』になると、それなりに身を清め、行いを慎まなければいけませんでした。その役を終えて、はじめて一人前の社会人として、周囲の人から認められたといいます。
次第に、この『役』の年齢に差し掛かる頃には、精神的なものや肉体的なことに変化が起こりやすく、体を壊したり、思いも寄らぬ受難を受けたりするという、人生の節目になっていることが分かってきました。昔の人は、厄年を『役年』とすることで、役についた者に様々な制約をもうけ、『厄』から逃れていたのです。
— yakuyear.com/about/what.html

やっぱり意味がわからない。僕の読解力がなさすぎるのか、ヤクヤク言いすぎているこのサイトのどちらかが悪い。明らかに前者だ。23歳くらいにもなれば、それなりの役を任されて、いろんなことがあるから頑張れ的なニュアンスだと思っておけばいいだろうか。

 

OK Google ここから一番ちかい神社は?

と話しかけてはみたものの期待通りの結果は得られず、普通に検索した。わからないことがあったら検索する。それでもわからなければ誰かに聞けばいい。昼休みに先輩につれられて、真相を確かめに近くの神社へ向かった。

 

 

今年のクリスマスのみなとみらいには、福山雅治がいろんなところにいる。福山雅治にも厄年があったのだろうか、あったはずだ。あったと信じたい。

 

 

平日の昼間だというのに、桜木町とみなとみらいをつなぐ動く歩道には沢山人がいる。さすが観光地だ。

 

 

場所がわからず、遠回りをしてしまった。正直、桜木町駅は通らなくてもよかった。

 

 

現在、弊社で開発を進めているの新プロダクトについて先輩と話しながら神社にたどりついた。

 

 

 

 

 

 

 

たどりついた、が....

 

 

 

 

 

 

 

 

 

 

工事中だった。

 

 

 

 

 

おわりに

アドベントカレンダーをご愛読いただき、ありがとうございます。今日でアドベントカレンダーも終わりです。新人という立場ながら、ブログを書かせていただけたことをとても嬉しく思います。弊社は高い技術力を持ったエンジニア集団です。自分は、まだまだヒヨッコプログラマ故、このような記事しか書けませんが、ゆくゆくは技術的なブログやアウトプットも公開していければと思っています。

今年、新卒として働き始めたあなたも、来年新卒になるあなたも、研究を続けるあなたも、新しいステージ、新しい役で、活躍することを願っています。信仰心が強い、おばあちゃんや上司に怒られないように時間が空いた際は、厄払いをしに神社へ出かけてみてはいかがでしょうか。


アットウェアではエンジニアを募集中!

Scala先駆者インタビューも絶賛公開中!!

 Scala先駆者インタビュー VOL.3 ビズリーチ竹添さん 〜後編〜

Scala先駆者インタビュー VOL.3 ビズリーチ竹添さん 〜後編〜

なるほどわかった!?色彩のお話し

なるほどわかった!?色彩のお話し

みなさんこんにちは。不破@エンジニアです。最近はWordPressのお仕事を頂いており、高速WordPressを実現させるべく日々がんばっております。あと最近はスプラトゥーンにはまりつつある感じです。

今日のテーマは「色彩のお話」です。 最近のアプリケーション開発ではプロトタイプを制作するケースが非常に増えてきました。 Bootstrapの登場や普及などもあり、デザイナーやコーダーではないエンジニアもWebアプリケーションやスマートフォンアプリのプロトタイプを開発するようになりました。 その一方で、色彩についてよく考えないスマートフォンアプリやWebサイトが増えているように思えます。

そんな私もデザインや色彩については素人です。色々思うところがあって、色彩検定3級の勉強をしています。 今回は、エンジニアが知っておくべき色彩の知識についてまとめました。

色の三属性

「色の三属性」は学校で習った人も多いと思います。色には

  • 色相
  • 明度
  • 彩度

があります。 色相は「色みの違い」を意味し、「青緑」「紫」「赤紫」など10の色相がJIS規格で決まっています。 色相を順番に配置したものを、「色相環」(下図)といいます。

色相環

Wikipedia 色相

明度は「明るさ」を示し、彩度は「鮮やかさ」を示します。彩度が低くなると灰色に近い色になり、逆に彩度が上がると派手な色になります。

補色

色相間の対面にある色の組み合わせを「補色」といいます。 先ほどの色相環図を見ると、非常におおざっぱな見方をすると「赤」の補色は「緑」になります。

補色は、背景色を決定するのに使用します。たとえば、「赤色文字の背景色」を考えましょう。今回は背景色の上に文字(「あ」)を描いてみます。

「赤」の補色は「緑(緑と青を混ぜた感じ)」です。補色を背景にすると、こうなります。

赤文字と青緑

いい感じに赤色の「あ」が映っています。これなら「あ」という文字をすぐ認識することが出来ます。

今度は補色ではなく、色相環的に隣り合わせの色を組み合わせてみます。するとこうなってしまいます。 青と青緑

お互いの色が似通っているせいでよくわからなくなりました。 このように、補色になっていないと読みにくくなります。

Webサービスで「なんかこの色見にくい・・・」と感じた場合、「お互いに補色になっていない」ことが多いようです。

色がもたらす心理的効果

「暖色」と「寒色」

赤・橙・黄のように「暖かさ」を感じるような色を「暖色系」といいます。 この時期にヨドバシカメラの暖房機コーナーに行くと、オレンジ色や赤色をベースにしています。暖房機コーナーにある色は基本的に「暖色系なんだ」と思っていただけるといいとおもいます。 文字通り「暖かさ」を示すだけではなく、食欲を訴える色としても使われます。食品パッケージにもよく使われています。また、レシピサイトにも暖色系を使ったサイトが多く見られるのもこのためだそうです。(寒色系が全く使われないわけではありません。)

逆に青系の色は「寒色」といい、文字通り涼しさを感じます。夏になるとヨドバシカメラでエアコンコーナーへ行くと青基調の配置になっているのはこのためです。 また、夏のかき氷やアイスも寒色系を使うことで涼しさを引き立てています。この場合は「おいしい!」よりも「涼しい!」をアピールするために寒色系の色を使うことが多いみたいです。

Webアプリケーションを作るにあたっても、ターゲットに合わせて「暖色」「寒色」を意識してみましょう。 たとえば、食品を扱うサイトであれば明度を低めにしたオレンジ色を使うなど考えることができます。プロトタイプ開発にあたっても、この点だけでも気にしてみるとだいぶ変わります。

色の「視認性」

これはドキュメントを作る時にも心掛けたいポイントです。文字が読みにくいWebサイトになってしまうと、PV数にも直結することになるので注意が必要です。 色の視認性は「背景との明度の差(コントラスト)が大きい」ほど認識しやすくなります。 明るい背景色に対して文字を載せたい場合、明度が低い(黒色など)色を選択します。

違和感を感じたら?

開発中のUIに「なんか見にくい・・・」や「目が疲れる」といったことを感じることが多々あると思います。 ただ、デザイナーさんに「なんか目に悪くない?」と言っただけではなかなか理解されないこともあるかもしれません。 そんなときに、「補色にすればどうですか?」のような具体的な用語が使えると、デザイナーさんにもスムーズに理解してもらえます。

間違いがあったら

この記事は素人が書いています。参考文献をベースにしながら書いていますが、間違いがありましたらお手数ですが不破までメール(fuwa at atware.co.jp)でお知らせください。できるだけ早く修正します。

明日はどうなる?

気づけばアドベントカレンダーも明日で終わりのようです。今年もあとわずかで、今週金曜日は弊社の最終営業日です。 ラストを決めるのは、あの新人です。

参考・引用文献

今回この記事を執筆するにあたって、下記の書籍を参考にさせていただきました。 また、色相環の画像はWikipediaより引用しています。 Wikipedia 色相

いずれの本も、デザイナーではない私が読んでもわかりやすい内容で今後の開発にも活かしたい内容でした。年末休みに更に深く読んでいきたいですね。

みなとみらいの冬

みなとみらいの冬

こんばんは。アットウェアの女子社員です。

みなとみらいで働く私たちにとっては、「みなとみらい」は職場ですが、観光やショッピング目的で遊びにくる方も多くいらっしゃるとおもいます。 (いやいや、むしろ、そういう人の方が多いでしょぉ)

「みなとみらい」では、季節に応じた様々なイベント/催しが開かれ、毎日「みなとみらい」に出社する私たちは、仕事をしながら四季折々の「みなとみらい」を楽しむことができます。

さて、もうすぐ今年が終わろうとしているこの時期にあるイベントと言えば、Xmasですね。

そうなんです、さすがは「みなとみらい」。色々なXmasツリーやイルミネーションをみることができます。

atWare Advent Calendar 2015 の22日目は、この時期だけ楽しめる「みなとみらい」を写真でご紹介します。

では、さっそく、定時後、このオフィスを起点にぐるっとカメラ女子風に徘徊してきたルートに沿ってご案内します。

まずは、私たちのオフィスのあるみなとみらいセンタービルのXmasツリーです。 このオフィスに移転してきたのが12月だったこともあり、移転当日、このツリーをみて感激したことを覚えています。 ココだけのお話ですが、このビルでは何度かCMや雑誌の撮影をしているのをみかけたことがあるんです。そうなんです、お仕事の合間に有名人をみることもできちゃいます。

続いて、お向かいにあるクイーンズスクエアの入り口です。

一度建物に入り、そのまま通り抜けてat!のテラスに出ます。 すると、コスモワールドの観覧車を背景に素敵なイルミネーションをみることができます。 ココでは、スマフォで自撮りをしている方がたくさんいました。

再び、建物に入り海の方へ歩きます。すると、「キューピッドツリー」が出現します。 このツリーは1日に6回、音と光のショーが行われます。

それでは、来た道を戻って桜木町方面へ建物の中をずんずん歩きます。一度、外に出されますが、そんなことは気にせずに、ランドマークプラザへ入り、またまた、ずんずん歩くと真ん中あたりにツリーが現れます。おそらく、ツリーとしては「みなとみらい」で一番有名な場所です。

はい、そうなんです。何も知らずにココへ来た私は驚きました。 例年とは趣が違うのです。ココでも決まった時間になると音楽が流れ、ツリーと名曲を一緒に楽しむことができるので、得した気分になります。

さて、次は、建物を出て道路を渡って、マークイズへ移動します。

お気づきでしょうか。実は先ほどのツリーと対になっています。 ランドマークは「強さ」。そして、マークイズは「やさしさ」をイメージしているそうです。

それでは、せっかく入った建物をまた外にでて、横浜側に道路を渡ると、そこはみなとみらいテラスです。ここでは、水を使ったイルミネーションをみることができます。

そろそろ、体も冷えてきたのでオフィスに戻ります。

このブログでは最後になりますが、私たちアットウェアでもXmasツリーを飾っています。

ここでは紹介しきれないほど、たくさんのイルミネーションやツリーが「みなとみらい」では楽しめます。みなさんもぜひ一度、「みなとみらい」にいらしてみませんか?

さて、今年のAdventCalendarも後2日となりました。 明日は、札幌から来た彼が素敵なお話をしてくれます。

社内用のChrome Extensionを作って公開した話

社内用のChrome Extensionを作って公開した話

この記事は atWare Advent Calendar 2015 の19日目の記事です。

みなさん、こんにちは。最近モンハンXにハマっている武永です。

今回はモンハンの話!!。。。。。は全く関係なく、社内用にGoogleChrome Extensionを作って公開した話をしていきます。
モンハンの話をしてもいいのですが、会社のブログですることではないということで。。。
最後の抵抗に画像だけモンハンを使いましたが。。。

何を作ったのか?どうして作ったのか?

作成したものは一言で言ってしまうとGmailからBacklogの課題にスターを付けるというものです。
atWareでは課題管理にBacklogを使っています。
そして日報・週報・月報をBacklogに課題として書いていくという取り組みをしています。(日報などを課題として上げるという運用はどうなんだという話は今回は脇に置いておきます)
Backlogには課題にスター(いいねのようなもの)を付けることができます。日報などをせっかく書いたのに反応が少ないと悲しくありませんか?モチベーションが下がりませんか?
私はモチベーションが下がる1人です。
こういう状況に他の社員の人にはなってほしくないけど日報などに毎回コメントを書くのも難しいよね。ということで私は「日報を読んだよ!!」という意味も込めてスターを付けています。

課題を追加するとメールが送られてくるのですが、そのメール内には課題の内容が全て書かれています。
メールを見るだけで日報は読めているのに毎回その課題にBacklog上でアクセスしてスターを付けるのも面倒だなと感じていました。
大した手間ではありませんが、自分の勉強のためと少しでも楽になればいいやということでメールから直接スターを付けれるようにしよう!と考えて作り始めました。

最初は公開する気はあまりなかった

前述の通り自分の勉強のためという理由も大きかったので作っても社内で公開するという考えはありませんでした。
では何故公開しようと思ったのか。
atWareではatWare Awardという社員が何か作成したものを出品するコンテストがあります。(atWare Awardの詳細は今回は省略させていただきます)
そこで作ったChrome Extensionを発表した結果

公開して欲しい
Chrome ExtensionだけではなくFirefox アドオン版も欲しい

という声があって、「あー意外と需要あるんだ」とそこで初めて実感しました。
それなら公開しよう!!ということで社員限定で公開し始めました。

公開した結果

自分の環境だと安定して動作していたので公開しても大丈夫かなと思っていました。
しかし、いざ公開してみると

エラーのalertが出た
APIキーを入力する画面が出てこない

など結構問題を指摘されました。
環境差分ってやっぱりあるのかーというのが感想です。
自分の環境で動いたからと言って必ずしも動くわけではないという基本的なことが頭から抜け落ちていました。
Chrome Extensionは内部のコードを見ることができるので簡単にコードレビューをしてくれた方もいました。
そこで指摘されて気づいた不安定要素などもあったのでありがたいですね。

自分で作って自分で動かして満足するのではなく、公開して他の人にも使ってもらうことで自分の成長にも繋がると改めて実感した出来事でした。

最後に

色々と不具合もあったのでもっと安定したものを作っていきたいなと思っています。
あと要望もあったFirefox アドオンも作ってみたいですね。(まだ全然手を付けられていない)
今回で社内用のツールって使われる、使われないはとりあえず置いておいて、自分の気づいたところから作ってみて公開していいんだ!!というモチベーションに繋がりました。
自分の勉強にもなるし、上手くいって使われるようになるといいなぁと。。。

一緒に働きたいと思える人

一緒に働きたいと思える人

この記事は atWare Advent Calendar 2015 の17日目の記事です。

どうも、こんにちは。三嶋です。atWare Advent Calenderの15日目、16日目と新人のネタが続いていますが、3人目となる僕も、新人目線で今までのことを振り返りたいと思います。 なお、本記事の内容は以前に投稿した記事にを参照改変した日本語版となりますので、英語で読みたい方はそちらもどうぞ。

2015年4月にatWareに入社してから半年以上が過ぎました。私の出身は北海道の函館にある、函館高専専攻科というところです。 学生時代は主に機械工学を専攻していましたが、授業以外では主に機械学習やプログラミングなどに興味を持って勉強してました。 現在は、社外でエンタープライズ向けのWebアプリ開発のプロジェクトに参画しています。

atWareとの出会いは約2年前の夏季インターンシップに参加したことがきっかけでした。当時は、学校で習ったC言語以外のプログラミング言語には触れていなかった上にアプリ開発などの経験もありませんでしたが、学校で習った以外のプログラミングなども勉強たいという気持ちは持っていました。その時、たまたまatWareからのインターンシップ募集を見つけて、参加申し込みをしました。 函館に居た当時はIT企業というもの自体にかなり固いイメージを持っていたせいか、atWareのブログをみながら、仲良さそうに写真とってるなーとか思ったり、プログで社員の方のボケを交えた投稿など(もちろん心に響く名言を連ねた素敵な投稿もありました)を見てはどんな会社なのか、どんな人たちなのだろうかと興味深々だったのを憶えています。 インターンシップに参加した際にも、社員の方とのコミュニケーションは楽しく感じられましたし、みんなで一緒にランチを食べる機会を毎週設けたり、朝のゴミ捨て当番をダーツで決めたりと社員同士の交流を大切にしていた雰囲気にとても好感を持ちました。

 学生当時に観ていたatWareブログに載っていた写真

学生当時に観ていたatWareブログに載っていた写真

就職活動などで会社を選ぶ際には、働く場所、勤務体制や福利厚生、会社の雰囲気など多々考慮することがあるかと思いますが、私は「人が多すぎない」ことと「そこで働いている人に共感を持てるか」ということが特に重要だと思っていました。 人が多すぎなければ、自分の会社でどんな人が働いているのかというのが見えやすくなりますし、社員同士のつながりというものがより深めやすいだろうと考えていました。atWareはすでに"アットホーム"な雰囲気を持っており、社員同士がお互いを気にかけ合うようなことを自然にやっているなと感じました。その雰囲気に自分も混じりたいと思いました。 インターンシップを受ける前は自分が将来何をして働きたいのかという部分にばかりフォーカスしていましたが、インターンシップをきっかけに、誰と働きたいのか、どういった雰囲気で働きたいのかというところが自分の中では重要な観点に変わりました。 atWareの入社試験を受けた際には自分のIT技術に対する知識や経験が不足していることは自覚していましたが、一緒に働いてみたいという思いを持って試験を受けて縁あって、現在に至るというところです。

現在では、atWareという会社の雰囲気を作っている社員の皆さんと同じ雰囲気で働けていることが楽しいと感じますし、自分を偽ることなく素直に表現できているのかなと感じています。 社外のプロジェクトで関わる人達のみならず、帰社した際には気軽に自分に声をかけてきてくれたり、色々なアドバイスをくれる人達自分がいて、入社前に思っていたような雰囲気を感じることができています。これからは、より一層自分からも積極的に声をかけたり、自分にエネルギーをあたえてくれる雰囲気を持続していけるように行動できたら良いなと思います。

私の住んでいた地域はIT企業が少なく、atWareという会社が刺激的で印象強かったのかもしれませんが、関東に出てくると又さらにいろんな企業があって、それぞれが面白い文化を持っていると思います。新しい環境からくるストレス、一人暮らし、遠距離恋愛など不安な要素は多々あるかもしれませんが、ネガティブな気持ちは取り去って一度関東に出向いてみると新しい発見があるかもしれません。様々なコミュニティーや勉強会も沢山開催されているので、そこに参加して交流を広げるなど、今後私自身も積極的にチャレンジしていきたいなと思います。 では、新しい出会いを楽しんでください!

明日は、ここ最近大活躍のあの人です!!!!

atWareでの僕の生活

atWareでの僕の生活

Xin chào mọi người tôi là Nam, tôi đến từ Bình Dương, Việt Nam. Ngày 6 tháng 6 năm 2015, một mình tôi rời xa đất Việt để đặt chân lên đất Nhật, điều đó đồng nghĩa với việc tôi không thể gặp mặt bạn bè, gia đình, thầy cô khi tôi muốn. Làm việc trong một môi trường mới, ăn những loại thức ăn mới và tiếp xúc với những người mới đó là tương lai của tôi ít nhất là trong vài năm tới. Nhưng tôi luôn có niềm tin rằng, mọi thứ mới sẽ dần quen, mọi thử thách sẽ được vượt quá, mọi khó khăn sẽ có giải pháp. Mỗi lúc tôi gặp khó khăn tôi luôn nói với chính mình “everything will be ok”. Hơn 6 tháng ở đây, mọi thứ với mình trở nên quen thuộc. Giờ đây tôi có thể tự làm nhiều thứ, tôi đã có thể giao tiếp về công cuộc sống hằng ngày bằng tiếng Nhật với mọi người. Mỗi ngày sau mỗi giờ học tiếng Nhật tôi lại trở về nhà “Công Ty" của mình và bắt đầu một ngày làm việc.

Công ty của tôi mọi người thường hay gọi với cái tên rất gần gũi là atWare. Lúc mới qua tôi cũng không biết cái tên này có ý nghĩa gì nữa. Tôi đã nghĩ đi nghĩ lại nhiều lần thì thấy là nó vô nghĩa. Thực tế chứng minh là tôi đã sai vì nó có ý nghĩa từ lúc công ty thành lập, chuyện đó là 13 năm về trước lúc đó tôi chỉ là thằng học sinh cấp 2 chưa biết gì :D. Nói về ý nghĩa tên công ty thì nó là cả một câu chuyện dài nên mọi người có nhả hứng thì liên hệ với tôi qua gmail “lainam@atware.co.jp” tôi sẽ trò chuyện cùng bạn.

 ベトナムと日本の学生がインターンシップで夏にatWareで働きました。

ベトナムと日本の学生がインターンシップで夏にatWareで働きました。

Nói về những người quyền lực ở atWare thì có 4 vị lãnh đạo đó là xếp: Kitano-さん, Makino-さん, Matsudate-さん, Shigeta-さん. Nhiều năm trước 4 vị gặp nhau và cùng chung một mục tiêu "Make people happy with software services". Các bạn cùng trang lứa với tôi gồm: Mas-さん, Yanouさん, Hirakuさん, Huyさん, Takenaga-さん. 4 người bạn cùng trang lứa với tôi thường xuyên nói chuyện, giúp đỡ tôi nhất có lẻ họ hiểu cái tôi muốn, cái tôi quan tâm là gì và luôn luôn sẵn sàng giúp đỡ lúc tôi cần. Những đồng nghiệp và là cấp trên đáng mến của tôi: Ishigami-さん, Shiho-さん, Satake-さん, Kuriyama-さん, Jeff-san, Araki-さん, Akagi-さん, ... Mỗi người đều có một quê hương, tính cách, công việc khác nhau nhưng đều có chung đức tính là siêng năng, chăm chỉ, tốt bụng.

Mỗi ngày sau khi kết thúc việc học tiếng Nhật ở trường thì tôi cắp sách lên công ty để làm việc. Trước khi vào công ty tôi thường tự mua cho mình một 弁当 (hình như là cơm hộp thì phải) và cùng ăn với mọi người ở trên công ty. Công ty atWare của tôi có rất nhiều phòng (giành cho nhiều mục đích khác nhau) và tôi thường chọn khu vực nhà bếp để ăn, Nguyên nhân đơn giản là vì ở nhà bếp có bánh trái, nước uống tha hồ lại có cả bảng đen, tôi thường vừa ăn vừa học nơi ấy. Ông bà thường có câu vừa ăn vừa học nuốt hết chữ, mà tôi chả quan tâm lắm đâu. Vừa ăn no, vừa nhớ được tiếng Nhật là vui mãn nguyện rồi ^^.

 お弁当をMARK ISで買って食べます。安くないですけど、おいしいです。

お弁当をMARK ISで買って食べます。安くないですけど、おいしいです。

 kitchenで食べながら、日本語を勉強しています。

kitchenで食べながら、日本語を勉強しています。

Sau giờ ăn thì công việc buổi chiều bắt đầu, mọi người lại tập trung vào màn hình máy tính và coding. ở công Ty tôi thì mọi người họp rất thường xuyên, Một ngày họp 2 3 lần là chuyện bình thường ở atWare, riêng bản thân tôi thấy họp nhiều rất có ích, họp nhiều giúp mọi người làm cùng dự án hiểu hơn về vấn đề đang có, đang tồn đọng, hiểu hơn về việc đang làm, sẽ làm, giúp cho công việc và giao tiếp giữa mọi người được thuận dễ dàng hơn. Đôi lúc làm việc căng thẳng tôi thường cầm máy tính đi hết chỗ ngày tới chỗ kia để thay đổi không khí (tất nhiên là ở trong công Ty), không muốn ngồi thì đứng làm việc cũng rất tốt, thỉnh thoảng tôi thích phòng cách vừa làm vừa đứng thế này, chân, tay, não đều hoạt động cùng một lúc (mỏi ơi là mỏi ~~). Gần chỗ tôi làm là một gian hàng lớn nhỏ các loại bánh, đủ chủng loại từ viên cho tới miếng loại nào cũng ngon ngang nhau. Mỗi khi đi ngang qua tôi hay bốc vài bịch nhỏ mang tới bàn làm việc để trau dồi thêm năng lượng để có sức chiến đấu tiếp. Về đồ ăn thì đó chưa phải là thứ tôi thích nhất, cái tôi thích nhất là 1 tủ lạnh kem tha hồ mà lựa chỉ với ¥100. Không khi nào nó hết kem cả, hết lại đầy lại.

 この冷蔵庫にはいろいろな飲み物やアイスクリームがたさん入っています。

この冷蔵庫にはいろいろな飲み物やアイスクリームがたさん入っています。

 0円で食べられます。

0円で食べられます。

    Buổi chiều tối từ văn phòng atWare nhìn ra bên ngoài rất là đẹp, bạn có thể ngắm hoàng hôn tại đây và chụp ảnh bạn thích. Từ 7h trở đi bạn có thể ra về nhưng mỗi thành viên trong đại gia đình atWare chúng tôi thường ở lại lâu hơn, không biết vì sao có lẻ do nhiều việc cũng hoặc có thể là do nét văn hoá của công Ty nhưng nó thật đáng quý làm sao.

 atWareからは夕日がみえます。とてもきれいです。

atWareからは夕日がみえます。とてもきれいです。

    Giấc mơ của tôi sau này trở thành một kiến trúc sư phầm mềm

明日は丁寧な彼が登場します。 (本文の日本語訳は準備中です) 

2015年度、新入社員になった僕らは来年...

2015年度、新入社員になった僕らは来年...

僕の名前は山本真平。出身は北海道。公立はこだて未来大学を今年卒業して、晴れて4月からアットウェアで働き始めた。大学のころまで「ヤマ」などと呼ばれていたが、いろいろあって関東では「マッサン」と呼ばれている。そして名乗っている。案外気に入っている。

会社でアドベントカレンダーが始まって、もう半分くらいのところまで来てしまった。最近は忘年会シーズンということもあってか幹事などの仕事が重なって、アドベントカレンダーのことなどすっかり忘れていた。なにせ僕の本業はプログラマーであり、そういったことは広報がやってくれればいいのだから。とは思いつつも弊社は広報は広報以外の業務が多すぎて機能していない。おかげで会社は回っている。みんなの協力があってこその弊社なのだ。

というか、アドベントカレンダーってなに?くらいの次元にいる僕はこの盛り上がりを上手に享受できないでいた。もともとアドベントカレンダーとは、クリスマスに乗じて発火するイベントで、クリスマスがくるまでの日々を待ちわびる子供たちのためのものである。というのは、僕の勝手な解釈であり、Wikipediaでは以下のように書かれている。

アドベントカレンダー(Advent calendar)は、クリスマスまでの期間に日数を数えるために使用されるカレンダーである。アドベントの期間(イエス・キリストの降誕を待ち望む期間)に窓を毎日ひとつずつ開けていくカレンダーである。すべての窓を開け終わるとクリスマスを迎えたことになる。
 Photo by Jupiterimages/Polka Dot / Getty Images

Photo by Jupiterimages/Polka Dot / Getty Images


写真からもわかるように、誰もがどこかで見たことがあるであろう、あれのことをいうらしい。

アドベントカレンダーの起源は、19世紀の初頭まで遡るらしい。そのころ日本にはクリスマスを祝う文化があっただろうか、僕にはわからない。

Wikipediaにも記載されているように、IT企業界隈では、毎日ブログを投稿していくイベントがいつからか流行り出したらしい。弊社も頑張ってここまで繋いでるらしい。


22歳の新卒が北海道から出てきて感じたこと、思ったことを書いてくれと広報的なきれいな人に言われたが、ここまでアドベントカレンダーのことしか書いてない。実際感じてきたことなど多すぎて、書ききれない。さらに言えばこの仕事が始まるまでの朝の数分でまとめ上げることなどできるわけがないのである。

 

ただこれだけは言える。早生まれの酉年で今年会社に入った、もしくは入らなかった諸君、

 

 


来年の僕たちは....

 

 

 

 


前厄だ。

 

 

 

 

 

思い悩む僕のもとに先輩が寄ってきてこんなことを言った。「これから、神社行くぞ」

 

 

 

僕「???」

massan

 

次回のマッサンのブログは、「23歳で前厄になるのでお参りしてきた。」です。
乞うご期待。

 

明日は僕が会社で一番愛する彼の登場です。
つながれ僕らのアドベントカレンダー。

組織改革

組織改革

Advent Calendar12日目です。

弊社ブログ愛好家の皆さんは既にご存知かと思いますが、創立から12期目、和漢風な1巡目の締めに新たなチャレンジへの決意を込め数々の変革を行っています。

その大きな変革の目玉の一つが組織改革。
11期まではチームを単位にチームリーダが中心となり自律した活動を行う小さな組織型。かつ全7チームのリーダと取締役にて意思決定を行う少数指導型で進めてきましたが、新たな期を前にどのようにチーム、組織を再編するか、全社員で喧々諤々議論の結果辿り着いた新組織の形態は。。

北海道から横浜に移住して良かったこと・困ったこと

北海道から横浜に移住して良かったこと・困ったこと

みなさんこんにちは。北海道出身のエンジニア 不破です。

今回は、「地方に住んでいるけど、関東でお仕事してみたい!」という人向けに書いています。

2年前まで北海道にいました。

私は生まれも育ちも北海道(ほとんどを函館で生活し、札幌で就職)です。ちょうど2年前までは北海道札幌市で仕事をしていました。(ちなみに今と同じくWebアプリケーション(+インフラ構築担当)エンジニアでした)

そこから数ヶ月後、「内地でも仕事してみたい!」という思いから横浜に移住してアットウェアに入社しました。

※「内地」(ないち)とは、関東のことを指しています。北海道の人はこの言葉を使うことが多いようです。私も使っています。

今回のAdvent Calendarは、内地に引っ越してきて困った事などなどを書いてみようと思います。

よかった事

まず良かったことから書いていきます。

勉強会・イベントがとにかく多い

札幌でもIT系の勉強会は結構開催されているのですが、東京での開催数には遠く及びません。 connpassで見ても東京開催のイベントが圧倒的に多いです。 実際、横浜に引っ越してきてから勉強会への参加数が増えた気がします。

Amazonの荷物がその日に届く

横浜に引っ越してきて驚きました。「注文したその日に荷物が来るなんて!」と・・・

北海道の場合、「お急ぎ便」で注文しても届くまで中1日ぐらいかかります。「当日お届け便」は完全にエリア外ですし、最近始まったAmazon Prime Nowもありません。

なので「翌日に届く」というのはカルチャーショックでした。というか、1時間で届くってのもなかなかすごいですね・・・

ちなみに、北海道(地域にもよりますが)では雑誌など出版物も発売日から数日遅れて書店やコンビニに並びます。更に冬になると悪天候などで更に遅れます。

その他、

  • 日帰りでコミケに行ける
  • 気軽に秋葉原まで電子部品を買いに行ける

などなど色々あります。

困ったこと

家賃が高い

とにかく家賃が高いです。札幌では1Kのアパートに住んでいたのですが、その時の家賃は3万円でした。しかも地下鉄駅(南北線麻生駅)から徒歩10分以内で大通やすすきのへ行きやすい立地でした。

そして横浜へ引っ越してきたのですが、家賃が2倍の6万円になりました! さらにワンルームになったので部屋の広さも半分になりました!

引っ越した直後は敷金の支払いもあったので、一時期家計が大変なことになりました。

住民税が高い

札幌市に納めていた住民税と比較すると、横浜市の住民税が2倍ぐらいになりました。(年収が上がったというのもありますが・・・)

その他物価が高い

北海道にはセイコーマートというコンビニチェーンがあるのですが、ここだとやきそば等お惣菜1パックを80円ぐらいという驚きの価格で買えます。勿論横浜にはそんなのありません。

また、札幌で仕事中にお昼を食べに行くと大体500円ぐらいで定食が食べられるのですが、横浜になると1000円を余裕で超えます。 外食ばかりだと家計が圧迫されるので、自炊する回数が増えた気がします。

ちなみに札幌では1000円出すと寿司が食えます。

お寿司

500円出せば、これぐらいの大きさの親子丼が出てきます。

究極の親子丼

意外と交通機関が貧弱だった

東京・横浜にはJR/東急東横線/みなとみらい線/市営地下鉄などなど交通機関があり、充実しているように見えます。 ただ、どこかで人身事故が起こると玉突き式に他の路線が遅れ出すなど、意外と貧弱だと感じました。

また北海道ではありえない事なのですが、東京で雪が降ると各線で運休まで出るというのには驚きました。

ちなみに北海道におけるJRの遅延・運休理由で多いのは

  • 大雪(それに関連するドア故障など)
  • 大雨
  • 鹿など動物をはねてしまう

だと思います。その他、車両火災も多い気がします。

・・・いかがでしょうか!まだまだ書きたいことは沢山あるのですが、これぐらいにしておきます。

まとめると、

  • 東京は勉強会がとにかく多くて楽しい
  • Amazon生活が捗る
  • ただし物価も家賃も高くなる。
  • たまには北海道に帰りたい!おいしいお寿司食べたい!

となります。要するに、土地それぞれにメリット・デメリットがあるということです。 自分の生活スタイルや自分自身のこだわりとあわせて考えてみるのはどうでしょうか。

それでは!

マフラー

マフラー

この記事は atWare Advent Calendar 2015 の8日目の記事です。

「仕事仲間にはすごく恵まれている」

仕事を初めて一番かな。

いままでに、いろんな仕事のやり方をいろんな人々から教えられた。

そして今年、意見を通してくれる機会が多く与えられた。

感謝。

この感謝を言葉で伝えるのは簡単だか、それは俺の流儀ではない。

「仕事でベストを尽くす」

それぞれ違う仕事を行い、関係性がそれぞれ違う。

仕事でどれだけ全力を出せたかを、客観的に見てもらうしかない。

今年は、今の自分のベストを伝えられたんじゃないかと思っています。

自分が関わる仕事を、今まで以上に仲間たちに楽しんで取り組んでもらう。

そのために、一層、”認められる人”を目指します。

というわけで、まじめにタイトルとはまったく関係なくなってしまいましたが、荒木でした。

次はなんとあのエンジニアの登場です。お楽しみに!!

第12期に向けて

第12期に向けて

このエントリは atWare Advent Calendar 2015 の第7日目です。

前回に続き、今日は第12期に向けての取り組みとして、事業方針の一部を紹介します。 当社のミッションは「システムで人々をしあわせにする」。今期もこのミッションを達成すべく、ここ数年の事業方針を踏襲した事業の推進と企業としての成長を図っていきます。

当社はこれまでSI/受託システム開発を請け負うことを主な生業とし、顧客である企業を通じて社会の人々に対してしあわせを届けて参りました。特に昨今は、システムが顧客企業の業務効率化を図る、つまりは企業のビジネスを支援するものから、システム自体がビジネスを駆動する、単なる便利なツールから企業のビジネスそのものであることが多くなってきました。システムを利用する人も一般のコンシューマーであり、利用する環境も多様化しています。当然ながら要求は多岐に渡り、また変化のスピードも速く、システムを開発あるいは保守する我々も顧客のシステム部門から言われたことをやっているだけでは、十分な満足を得ることはできません。顧客のビジネスそのものを理解し、その先にいる利用者に我々自身がしあわせを届けるんだという立場で顧客と共に働く、「恊働」をより強力に社内に浸透していきます。具体的には、従来から取り組んできたスクラムなどのアジャイル開発プロセスと保守と開発が一体となって取り組むDevOpsを融合したアットウェアメソッドを確立します。その上で社内で取り組む全てのSI/受託開発プロジェクトをこれに則って推進し、顧客企業との協働、さらにはより多くの利用者にしあわせを届けて参ります。

一方、ここ数年、取り組んできたTypesafe社とのシステム開発パートナーを中心としたReact SystemおよびNoSQLデータベースCouchbaseなどの大規模並列分散/並行データ処理技術に対しても、体制を強化すると共に社内外のナレッジも整備して、より高い価値、これまで経験したことのないしあわせを提供できるようにして参ります。具体的な取り組みも近いうちにお知らせできるものと思います。

また、当社がより多くの利用者に直接しあわせを届けるための施策も強化して参ります。こちらも近いうちにお知らせできるものと思います。

これらの事業をより強力にスピーディーに実行できるよう、社内の組織編成を大幅に改革しました。まだ試行錯誤で取り組んでいる段階ですので、いずれ整備が進み、成果が出てきたころにあらためてご紹介できればと思います。

毎年、中長期の方針とこれまでの反省を踏まえて、期首に事業計画を立てていますが、ここ数年それが十分には達成できないでおり、、経営者としての責任を痛感しています。 この一年は、これまで以上の覚悟を持って取り組んでいきます。社員の皆やパートナーさん、さらにはお客様と共に、より多くの人に、より価値の高いしあわせを届けていけるよう、精一杯努力していきます。

下呂温泉旅行

下呂温泉旅行

この記事は atWare Advent Calendar 2015 の6日目の記事です。

みなさん、こんにちは。矢納です。Advent Calendar 2回目の登場です。

今回は社員同士の交流について、紹介していきたいと思います。
今回、ランチや飲み会等のありきたりな紹介ではなく、11/28, 29に下呂温泉までのぷち旅行の様子を紹介したいと思います。

なぜ下呂温泉??

目的無しで旅行に行くのは個人的にはないと思ってます。今回の目的は「紅葉を見に行こう」です。会社に外国籍の方がいて、彼らが「紅葉見に行きましょう!」と行ってきたのが始まりです。それから社員に声をかけて、人集め、行く場所を決めるのですが、これが大変!
参加者の1人が「温泉は必須だよね!?」と言うのです。さらに温泉はそれなりの質を求めてきます。紅葉温泉が堪能できるところ。色々探しましたが良いところが見つからず困ってました。
ある時、ふと「下呂温泉」がひらめきました。流石に紅葉の時期じゃないだろうと思いましたが、紅葉の時期でした。半分冗談で言ったらそこに決定しました。
これで下呂温泉に行くことが決定しました。

計画

行く場所が決定したら、今度は行動計画を立てます。こういうのを作るのはとても楽しいので夢中になって作ってしまいますね。スライドで計画を作り、概算の予算を算出し、他のメンバーの同意を得ていく。面白いですね!!
ですが、計画を立ててる時に「計画通りに進む旅行なんてないけどなぁ」と思ってました(^^;

出発

計画も立てたし、宿も予約したし、これでOKですね。では出発しましょう!

今回は車での移動です。横浜から下呂温泉まで約370kmらしいです。推定5時間。レンタカーを借りて、朝8時に横浜を出発です。まずは東京メンバーを迎えに八王子まで下道で行き、その後高速になりました。休憩に使ったSAは談合坂双葉諏訪、神坂(PA)でした。

談合坂SAはEXPASAになっています。EXPASEとは“なんぞや”と思う方はとても大きなSAと思って下さい。ここで朝食?昼食?を食べました(英語だとbrunchです)。

双葉SAは富士山をきれいに見れるSAとして有名なところです。写真では伝えれませんが、なかなかにきれいに富士山を見ることができます。

諏訪SAには知っている人は知っている、温泉があります。私は知りませんでしたけどね(^^; ここは温泉もそうですが、諏訪湖が一望できるのでかなりいところですね。

もう一度休憩をはさみ、その後下呂に直行です。下呂についたころには17時になってました。

下呂温泉

17時についたので外は少し暗くなっていました。車を駐車場に止め、観光です。

最初は下呂温泉神社に行きました。神社と言っていますが、そんなすごいものではありませんでした(笑)。ちょっとした祠があるだけでした。

次に行ったのは、さるぼぼ神社です。ここはそれなりに有名らしくたくさん人がいましたが、神社にしてはかなり小さめかと思いますね。さるぼぼは写真に写っているものです。赤い体をしており、顔が無いですね。

その後、少し街を探索してホテルではない温泉に向かいました。巌立峡ひめしゃがの湯です。ここは炭酸温泉で有名です。この炭酸温泉は飲むこともできるし、料理にもつけます。なのでペットボトルに入れて持ち帰ることも可能です。また、化粧水の代わりにもなるとのことです。私は持ち帰っておりません。荷物になるので(笑)

夕食はこの温泉と一緒になっているレストランで食べました。私は飛騨牛の料理を食べました。写真は後ほど。

その後、ホテルに戻り、温泉に入って就寝です。一緒に行った人たちは疲れて寝てしまいました。せっかくトランプとUNOを持っていったのに......

二日目は合掌村に行きました。ここには少しばかりの紅葉がありました。そうです!ここでやっと紅葉が出てきました。ですが、少しだったのでこれは紅葉旅行ではなく温泉旅行だなと思いましたね。ここは古い民家、足湯等があってとても面白かったです。足湯は下呂にはたくさんあるのですがね(^^;

お昼はまたもや飛騨牛料理です。ひつまぶしのうなぎを飛騨牛にしたものです。とても美味しいので皆さん食べに行ってみてください。お店はせん田です。

おわりに

色々と楽しんだ後は帰るだけです。帰りのほうがやはり体力的にも精神的にはキツイですね。渋滞に2回。小仏トンネルと海老名なのでいつもなのですが......。他にも圏央道はとても走りやすかったりしてよかった部分もあります。

最後にみんなでの集合写真です。

いかがだったでしょうか。たまにこのようなこともやって、社員同士の交流等を深めています。
さて、明日は最近何かやりたくてたまらない方の登場です。

Email: yanou at atware.co.jp

GEEKSCHOOLって?

GEEKSCHOOLって?

こんにちは。 栗山です。 アットウェアに入社し、これまで色々な業務を担当させていただいておりますが、 今期からは広報・採用と、外への働きがメインとなる業務も行うこととなりました。

そこで、atWare Advent Calendar 2015 の5日目の今日は、広報担当のわたしから、 GEEKSCHOOLの紹介です。

では、さっそくですが、GEEKSCHOOLを紹介していきます。

GEEKSCHOOLとは?

私共、株式会社アットウェアと株式会社永和システムマネジメントさん、ウルシステムズ株式会社さんと力を合わせ運営している学生を対象とした勉強会です。 この勉強会や各種イベントでは、わたしたちの知識・技術・経験から、自分の道を既に決定している学生はもちろん、進路を決めかねている学生の方々に目には見えないプレゼントを届けています。

GEEKSCHOOLの対象は?

IT業界/進路に関連することで悩んだり困ったりしている学生のみなさんを対象としています。

  • 就職したら即戦力として働けるようになりたい。その為に、どういう勉強をしたらいいかを知りたい
  • 実際の現場ではどんな技術が使われているのか知りたい
  • 授業にはない技術を学びたい
  • IT系の授業は受けていないが、ITの技術を学びたい
  • 就職活動をする前に、IT業界がどんなところなのかを理解したい
  • ITエンジニアで働く人と仲良くなりたい
  • IT業界に興味を持っている学生の友達を作りたい
  • インターンシップに行く時間はないけど、IT業界のことを知りたい
  • SEとかPGとかって、実際は何をするのか知りたい

GEEKSCHOOLのウリ

  • 参加費が無料
  • 講師はすべて現役のエンジニア
  • オンラインで講師に質問ができる
  • 懇親会やハッカソンなどのイベントで受講生
  • 講師とコミュニケーションがとれる
  • 様々なプレゼント
  • などなど

GEEKSCHOOLの歴史

第1期

  • 2015/04/25 オープン記念イベント
  • 2015/05/01 第1期説明会&RaspberryPIミニハンズオン
  • 2015/05/08 第1期説明会&RaspberryPIミニハンズオン
  • 2015/05/14 第1期(Vol1) JavaによるWeb開発の最前線
  • 2015/05/30 第1期(Vol2) SQL 〜情報技術社会に一番無くてはならない大事な技術〜
  • 2015/06/11 第1期(Vol3) TDD & Pull Request ~動作するきれいなコードを目指そう~
  • 2015/06/27 第1期(Vol4) Javascript, React.jsを使ったWebページ開発のハンズオン
  • 2015/07/08 第1期(Vol5) アジャイル開発 ~チーム運営プロセスをゲームで学ぶ~
  • 2015/07/17 第1期(Vol6) システム開発の要。要件定義そのテクニック
  • 2015/08/08 サマーハッカソン
  • 2015/09/12 IchigoJamを組み立ててBASICを触れてみよう!

第2期

2016/1、2月開校予定

これから社会にでる方々の「これから」に少しでもお力になれるよう、講義内容を日々検討しています。 リクエストがある方は、ぜひ、ご連絡ください。

GEEKSCHOOLスタッフ一同、学生のみなさんにお会いできることを楽しみにしています。

では、明日の6日目は、凛々しい顔が板についてきた、若手の彼が再登場します!!

社員合宿2015

社員合宿2015

4日目ですね。リーダーを卒業し、雨の中でも毎朝走っているアラフォーの荒木です。

風邪気味で体調も悪い最近ですが(そりゃそうだ)、

さて、今年の9月に全社員が集まって2日間合宿を実施いたしました。

全社員が集まって話し合うのは何年ぶりでしょうか?

準備

準備は2ヶ月前から!!

目的、内容、会場プラン、ご飯の準備、インビテーションカード作成、会場設営などなど、

みんなで仲良く準備を行いました。

ご飯の用意楽しかったですね。

今回はワールドカフェで行いました。

ワールドカフェは、カフェのようなリラックスした雰囲気で対話を行う手法ですね。

まずは、やり方の説明。相手の話をよく聞き、相手の意見を否定せず、意見を受け入れ、深い洞察を行い、アイデアを掛けあわせ、楽しく会話を行うこと!

模造紙に気になったことを書き込んでね。絵でもいいよ!!

んっと、普段行わない感じなので、違和感ありますね。

今回は1ラウンド30分を5ラウンドを予定。途中でカフェタイムをいれて、楽しくすすめるように企画しました。

1ラウンド目スタート

ぎこちない感じで1ラウンド目!!

2ラウンド目スタート

こんな感じ?とおもいつつ、2ラウンド目!!

カフェタイム

美味しいミスド

3ラウンド目スタート

随分なれてきた3ラウンド目!!

和菓子タイム

美味しい団子

4ラウンド目スタート

なかなか終わらなかった4ラウンド!!

アイスを食べて、瞑想

うまいーーーー

5ラウンド目スタート

最後は落ち着いて。最終ラウンド!!

最後に

いろんなかたが、いろんな思いで来たとは思いますが、 主体的に望んでくれたことが一番よかったですね。

というわけで、

次はキュートなあの方です。お楽しみに!!

君はどのエディタ・IDEを使っている?

君はどのエディタ・IDEを使っている?

この記事は atWare Advent Calendar 2015 の3日目の記事です。

みなさん、こんにちは。矢納です。
昨日のブログから

明日はYanouさんによる「IntelliJについて」です。というのを期待したいと思います!えっ!?

と来ましたので、今回は開発するには欠かせないエディタ・IDEについて少しおしゃべりしたいと思います。

Integrated Development Environment

さて、みなさんはどのIDEをよく使っていますでしょうか?

  • Eclipse
  • Visual Studio
  • IntelliJ
  • NetBeans
  • Android Studio

などなど。たくさんありますね。Wikipediaにもたくさん書いてありますね。

以前、私はEclipseをよく使っていましたが、あるプロジェクトを境にIntelliJを使い始め、今や開発は全てそれを使って行うほどです。

最初はキーマップやプロジェクトの開き方、細かな設定等のやり方がわからず苦戦しました。その様子を見ている周りからも「IntelliJって何が嬉しいの?」などとよく言われました。と、いうことで個人的な意見を言わせてもらいます。

プラグイン導入が簡単

intellij-plugin.png

プラグインが対応しているファイルを開くと自動的に上図のようなレコメンドをしてきます。あとはInstall pluginsを押して、再起動でインストール完了です。
最初からプラグインを検索せずともファイルを開くだけでプラグインがインストールできます。

初期プラグインが色々と

IntelliJをインストールした時点で様々なプラグインがインストールされています。Eclipseだとm2eやandroid等は自分でインストールする必要がありますが、IntelliJの場合だとそれらがある程度最初に準備が整っています。これは楽ちんですね。

その他細かいところ

IntelliJからターミナルを開くことができ、その場でコマンドを実行できます。これで別にターミナル用にウィンドウを開く必要がありません。

他にも「いいな」と思うことはありますが、基本的には他のIDEでもできますので、省略です。

ちょっと?残念なところ

IntelliJにはcomminity版とultimate版が存在しています。

「大した差なんてないでしょε-( ̄ヘ ̄)┌」と思ったあなた!!

残念!それなりにあります笑。

  • 使えるプラグインの数がかなり減ります。
  • 補完機能がなくなる言語も出てきます。

これら2つだけでかなり開発がやりにくくなります。ultimateはそれなりのお値段ですので色々と悩んでから買って下さい。あっ、個人的にはIntelliJ押しです。

エディタ

エディタは正直なんでもいいと思いますね。私は開発は全てIntelliJなのでエディタは単なるメモにしか使っていないので、特に書くことは無いですね。

さいごに

エディタ・IDEの話をしようと思いましたが、結局IntelliJの話をしてしまいました。皆さん、使い慣れた開発のし易いIDE・エディタを使って下さい。他に乗り換えるときは3ヶ月ぐらいかかると思っていれば、どのIDEでも使いこなせますよ!!

明日はどんなときにでも頼りになる男の出番です。

Email: yanou at atware.co.jp

Vimで学ぶ「適切な速度」で処理をするということについて

Vimで学ぶ「適切な速度」で処理をするということについて

Vimで学ぶ「適切な速度」で処理をするということについて

この記事は atWare Advent Calendar 2015 の2日目の記事です。

昨年はボードゲームでリアルなコミュニケーションというタイトルでモノポリーについて記事を書きましたが、今年はモノポリーかVimのどちらの記事を書くか苦渋の末に迷ってVimをお題にしたので、イメージだけはモノポリーにしてみました。

今日書くエントリーは適切な速度で処理をするということをVimをとおして学んでみたいと思います。

Vimとは

一般的にVi互換で機能拡張が入ったエディタという事でプログラマやサーバー管理者などに普及しています。 弊社内の統計値によると72%の社員が今年になってこのエディタを使った事があるそうです。

このエディタの特徴として起動が速い事で一般的に知られています。もう少し突っ込んだ話しをするとVimというよりViが軽くてどこのサーバーにでもインストールされているということでしょうか。

さらにいうと、一般的なLinuxOSですとviコマンドがVimコマンドのvi compatibleモードのエイリアスとなっている事はわりと弊社社内をはじめVimを使った事ある人には知れ渡ってきていることですね。

さて、viコマンドの起動はなぜ速いのでしょうか?理由は結構わかりやすく、C言語で書かれてていることに加え、数十年速度や機能改善をされ続けた成熟したプログラムというのに加え、もう一つ大きな理由として余分な機能を読みこまず、起動しているという事です。

Vimの魅力としてカスタマイズできることにあります。VimはVim scriptというVim専用のスクリプト言語で機能拡張を行う事ができるのですが、デフォルトのVimではいくつかのデフォルトプラグインを読み込み起動しています。

ディストリビューションやカスタマイズビルド(例えばMacVimやKaoriyaパッチVimなど)版のVimによって違いはありますが、例えば

$ ls /usr/share/vim/vim73/plugin/
README.txt           netrwPlugin.vim      tohtml.vim
getscriptPlugin.vim  rrhelper.vim         vimballPlugin.vim
gzip.vim             spellfile.vim        zipPlugin.vim
matchparen.vim       tarPlugin.vim

私の環境のVimにはこんなプラグインがインストールされていました。 gzip.vimはvimでzipファイルを開いた時に展開せずにVimでアーカイブ内のファイルを閲覧・編集できるというプラグインです。viコマンドではこのcompatibleモードで起動するのでこのプラグインは読み込まれませんが、vimコマンドで起動すれば読み込まれてから起動します。

こういうデフォルトプラグイン数個なら体感的に差はありませんが、便利なプラグインがGitHubやvim.orgで公開されており、自分のスタイルに合った便利な機能を追加しようとプラグインをどんどん増やしていくと体感できるほどに遅くなる事があります。これは、Vimに限った事ではなく他のエディタでもよくあることですね。

ただ遅いだけではない

いよいよ本題に入っていきます。みなさんパフォーマンスチューニングの時に測定していますか? 今の時代なら感覚に頼らずメトリクスや速度測定をして数値に基づいてチューニングしていくのが一般的ですよね。

一般的な手法を用いて遅さを実感してみたいと思います。

VimはC言語で書かれてコンパイルされて実行されていますが、機能拡張は基本的にはVim sciprtという言語で動的に実されます。

まずは、Vimをプラグイン読み込みせず、compatibleモードかつvimの設定ファイルも読み込まずに起動速度を測定できるオプションもつけて起動してみましょう。

$vim -u NONE --noplugin --startuptime vim-startup.log

そうするとこんな結果になりました。

$cat vim-startup.log


times in msec
 clock   self+sourced   self:  sourced script
 clock   elapsed:              other lines

000.010  000.010: --- VIM STARTING ---
000.093  000.083: Allocated generic buffers
000.106  000.013: GUI prepared
000.494  000.388: locale set
000.500  000.006: clipboard setup
000.507  000.007: window checked
001.124  000.617: inits 1
001.137  000.013: parsing arguments
001.523  000.386: expanding arguments
005.239  003.716: shell init
005.492  000.253: Termcap init
005.535  000.043: inits 2
007.877  002.342: init highlight
007.880  000.003: sourcing vimrc file(s)
007.890  000.010: inits 3
007.910  000.020: setting raw mode
007.928  000.018: start termcap
007.950  000.022: clearing screen
008.044  000.094: opening buffers
008.047  000.003: BufEnter autocommands
008.051  000.004: editing files in windows
008.073  000.022: VimEnter autocommands
008.080  000.007: before starting main loop
008.681  000.601: first screen update
008.684  000.003: --- VIM STARTED ---

8msで起動できました。

VimScriptを読み込んで起動

こんな簡単な再帰呼び出しを行うシンプルなVim scriptを書きました。

$cat recursive.vim

"set maxfuncdepth=100
function! s:Recursive(count)
    "echo a:count
    if a:count > 1
        call s:Recursive(a:count - 1)
    endif
endfunction

call s:Recursive(1)

先ほどと同じ容量でVim scriptを読み込んで起動してみます。

$vim -S recursive.vim -u NONE --noplugin --startuptime vim-startup.log

結果を表示してみましょう。

$cat vim-startup.log

times in msec
 clock   self+sourced   self:  sourced script
 clock   elapsed:              other lines

000.006  000.006: --- VIM STARTING ---
000.077  000.071: Allocated generic buffers
000.088  000.011: GUI prepared
000.416  000.328: locale set
000.421  000.005: clipboard setup
000.427  000.006: window checked
001.019  000.592: inits 1
001.034  000.015: parsing arguments
001.421  000.387: expanding arguments
005.263  003.842: shell init
005.522  000.259: Termcap init
005.567  000.045: inits 2
007.934  002.367: init highlight
007.937  000.003: sourcing vimrc file(s)
007.947  000.010: inits 3
007.968  000.021: setting raw mode
007.985  000.017: start termcap
008.007  000.022: clearing screen
008.100  000.093: opening buffers
008.103  000.003: BufEnter autocommands
008.107  000.004: editing files in windows
008.332  000.080  000.080: sourcing recursive.vim
008.345  000.158: executing command arguments
008.346  000.001: VimEnter autocommands
008.351  000.005: before starting main loop
009.246  000.895: first screen update
009.248  000.002: --- VIM STARTED ---

なっ、なんと先ほど8msだった起動速度が9msになってしまいました。 1msも起動速度が遅くなってしまったらこれは非常に困ってしまいますね。 生産性が悪くなって仕方なくなるかもしれません。少し大げさでした...

Vim scriptの関数呼び出しを増やしてみる

先ほどは関数呼び出し1回だけだったものを100回の再帰呼び出しに変えてみます。 関数内では処理はないに等しいのでほぼ関数呼び出しだけのコストになります。

結果は下記の通り。

times in msec
 clock   self+sourced   self:  sourced script
 clock   elapsed:              other lines

000.008  000.008: --- VIM STARTING ---
000.090  000.082: Allocated generic buffers
000.103  000.013: GUI prepared
000.498  000.395: locale set
000.504  000.006: clipboard setup
000.511  000.007: window checked
001.193  000.682: inits 1
001.212  000.019: parsing arguments
001.740  000.528: expanding arguments
005.770  004.030: shell init
006.042  000.272: Termcap init
006.088  000.046: inits 2
008.466  002.378: init highlight
008.469  000.003: sourcing vimrc file(s)
008.479  000.010: inits 3
008.500  000.021: setting raw mode
008.518  000.018: start termcap
008.545  000.027: clearing screen
008.642  000.097: opening buffers
008.646  000.004: BufEnter autocommands
008.650  000.004: editing files in windows
010.080  001.279  001.279: sourcing recursive.vim
010.098  000.169: executing command arguments
010.100  000.002: VimEnter autocommands
010.105  000.005: before starting main loop
010.635  000.530: first screen update
010.638  000.003: --- VIM STARTED ---

先ほどは、9msで終わったところが10ms後半になってしまいました。 着目したいところがあるのでピックアップしてみたいと思います。

008.332  000.080  000.080: sourcing recursive.vim
010.080  001.279  001.279: sourcing recursive.vim

1回の関数呼び出しの際に80µsecだったところが、15倍ほど時間がかかっていますね。 関数呼び出し1つで数十µsecは遅いと感じましたか?速いと感じましたか?

あなたの普段使っている言語。例えばJavaやPythonやRubyやGoではどれくらいのコストでしょうか? 非機能要件でシステムのレスポンス要求のオーダーはどれくらいに設定していますか?

秒単位の事もあれば、msec単位のこともあります。これがレイテンシも含め数十msecで処理したいシステムなら致命的な程遅いのです。また、チリも積もればなんとやらでプラグインの用途によってはUIが体感的に遅いと感じてしまう事もあります。

そういう時にどういうアプローチがとれるでしょうか?

アプローチ

一般的なWebアプリと同じような発想のアプローチをとることができます。

Rubyでも速度を担保したい場合にnativeにコンパイルしたモジュールを部分的に利用することがありますね。同じようにVimからもネイティブなモジュールを呼び出す事ができます。 他にもVimではPythonやLuaのインターフェースを使うということもできますので、Vim script以外の言語を利用するというアプローチもありですね。

アプリケーションを丸ごと置き換えるのではなく部分最適というものです。

「適切な速度」で処理をするということについて

とは言ったものの、富豪的にリソースを扱える時代でもシビアにならないといけない時とそうでない時の差はやはり存在します。

Vimを例に出しましたが何ごとも適材適所で、実装でひたすらがんばるというのもやり方の一つですし、部分的なネイティブで部分的に最適化もいいでしょう。また、MessagePackやZeroMQのようものを使い、プロトコルを決めてロスを最小限にし効率良く処理するという、分割して粗結合にする方法もありかもしれません。

適切な速度を言語レベルで担保しようとするのか、システム全体で担保しようとするのか、それだけでも視点は違ってきます。

大きな視点で考えた場合には影響範囲は留まる所をしれませんね!! 非機能要件で必要な速度を担保しつつ、クラウドリソースを活用したうえでアーキテクチャ次第で色んなアプローチがとれるので、そこを考えていくのは本当に面白いです。

まとめ

本記事は@kamichiduさんの発表にインスパイアを受け書きました。 興味深い面白い発表してくださりそして発表後の小話にもつきあって頂きました。この場を借りて感謝の言葉をお伝えしたいです。ありがとうございます。

自分なりに普段の業務を通じて感じていた所がVimを通してあらためて気づけたというのは非常に面白かったです。なお、このエントリーはVim Advent Calendar 2015を兼ねません。

明日はYanouさんによる「IntelliJについて」です。というのを期待したいと思います!えっ!?

第11期ふりかえり

第11期ふりかえり

今年もatWare Advent Calendarやります!

例年、初日の12月1日はアットウェアの新しい決算期を迎える特別な日でもあります。今年も無事にこの日を迎えられたことを嬉しく思っています。創業から現在に至るまで、非常にたくさんのお客様に支えられ、多くのパートナー企業の皆さんにご協力いただきました。また、社員の皆が努力を積み重ね、共に歩んできてくれました。アットウェアに関わってくださった全ての人に感謝です!

ということで、今年も先期のふりかえりから。

先々期から取り組んでいる、次代を担う若いリーダーを中心とした自律したチーム体制への移行は、道半ばながら期待した成果を挙げつつも一方では様々な課題を抱える状態です。我々はルールや仕組みを大事に守ることが重要ではなく、常に課題を解決するためのカイゼンに取り組むことが重要と考えています。これまで諸々の課題解決を進めてもいますが、根本の部分で会社としてあるべき組織像を社員皆で議論をし、この新しい期を機会に大幅な改革を行うことにしました。その内容については、まだまだ試行錯誤でチャレンジしていく段階にしかありませんので、また別の機会に(良い成果報告ができることを願っています)。

受託のSIプロジェクトとしては、先々期から取り組んでいる当社としては大きな案件が一年を通じて厳しいながらも、サービスのローンチを迎えることができ、多くの学びを得るとともに、これから我々が進むべき道を確認することができました。その他の多くのプロジェクトでも様々な経験を積み重ねました。特にお客様との恊働を軸とした、創業時から取り組んできているアジャイルとDevOpsの経験は今後の当社の力となるものと信じています。

一方、昨年から模索してきていたReactive Systemへの取り組みが7月のTypesafe System Integratorの認定を経て、いつくかのプロジェクトで成果を挙げれるようになってきました。こちらはまだまだ道半ばではありますが、当社が力を入れて取り組む事業の一つとしてより高いレベルの技術を携え、今までにない価値を生み出していきたいと考えています。

また、SIとは異なるサービスへの取り組みは、ようやく形が見えてきて社内での利用を経て、近々ローンチできる見込みです。既にいつくかの企業様に関心を持っていただいていますが、より多くの企業、エンジニアをはじめとするたくさんの方々に使ってもらえるよう、より一層スピードを上げて開発していきます。

今年もたくさんの新しい仲間を迎えました。大きな可能性を秘めた新卒新人をはじめ、経験豊富なエンジニアあるいは元研究者なども加わり、より一層、様々なことにチャレンジしていける組織に育ってきていると感じています。また、恒例のインターンでもたくさんの将来ある若者を迎えました。仕事というもの、企業というもの、IT業界というもの、そしてアットウェアというものを肌で感じて、少しでも彼らの将来の一助になればと思っています。

決してこのような良いことばかりの一年であったわけではありません。むしろ、企業としての成長としてはまだまだ思ったようにはいけてない。経営者としての力不足を大いに感じる一年でもありました。この期末には、ほぼ初めて社員全員との面談をしました。皆が何を思い、何を考え、また私自身が何を考えているか、限られた時間ではありましたが、いくらかでも共有できたことは良かったと思っています。

社員皆が「システムで人々をしあわせにする」ことをミッションとし、より多くの人にしあわせを届ける、またより高いレベルのしあわせ・価値を届ける組織となれるよう、今後もお互いに切磋琢磨し、リスペクトし、成長できる仲間でありたいと願っています。もちろん、私自身がその先頭で皆を率いていけるよう、さらなる努力をしていく覚悟です。

今期こそ大きな成長を遂げ、我々自身を含めたアットウェアに関わる全ての人、あるいは今まで関わりのなかったより多くの人がしあわせになるようにします。 皆様のより一層のご支援を賜れますよう、お願いいたします。