Quantcast
Channel: TechRacho
Viewing all 2941 articles
Browse latest View live

JavaScriptでElement.styleがnullになって焦った

$
0
0

JavaScriptで要素のstyleがnullになってしまう事態が発生しました。

// 正常
document.getElementsByTagName('p')[0].style
=> CSSStyleDeclaration {alignContent: "",…}

// あれ?
document.createElement('p').style
=> null

結論としては、Content-Typeがうっかりtext/xmlになっていたのが原因でした。

試してみましょう。

<?php
header('Content-Type: text/xml');
echo '<?xml version="1.0" encoding="UTF-8"?>';
?>
<!DOCTYPE html>
<html xmlns="http://www.w3.org/1999/xhtml">
<head><title>sample</title></head>
<body><p>Hello</p></body>
</html>

コンソールからdocument.createElement('p').styleを入力すると、以下のようになりました。
Chrome以外では値が取れていません。

  • Chrome 46: CSSStyleDeclaration
  • IE11: undefined
  • Firefox 44: undefined
  • Safari 8: null

styleはDOM API CoreではなくCSS用拡張なので、XMLとして表示している場合には存在しなくて正常だと思うのですが、すべてのブラウザで表示上はHTMLモードであること、静的に存在する要素ではstyleが存在する(CSSStyleDeclarationが取得できる)ことから、気づくのに時間がかかった…

表示上はHTMLモードでAPI上はXMLモードみたいなこの挙動は仕様上どうなのでしょう、詳細調べてくれる親切な人がいたら歓迎です。

なお、HTMLの内容がXHTMLではない場合は、XMLエラーになります。xmlnsを指定しない場合は、XMLとして表示されます。

ちなみになんでtext/xmlになってしまったかというと、CocoaHTTPServerで何も設定しないでXHTMLを返したらそうなっていた、というのが原因です。


TPAC 2015 札幌に参加しています

$
0
0

昨年に引き続き、TPAC@札幌に参加しています。今年は日本開催ということで、前回より少し多めの人数で北海道に来ています。

CIMG1097

babaは主にCSS WGとDPUB IGに参加しています。現地からあまり早くもない速報をお届けします。

CIMG1107

TPAC 2015とは

TPACはW3C最大のカンファレンスで、1年に1回開催されます。昨年はアメリカSanta Claraで開催されました。

今年は2015/10/26(月) ~ 30(金)の5日間、札幌コンベンションセンターで開催されています。

なかなか斬新な会議も開催されているようです。

なかなか斬新な会議も開催されているようです。

サイネージは日本企業が準備しているようです。弊社も一部関わったらしい。

サイネージは日本企業が準備しているようです。弊社も一部関わったらしい。

Japanese Industry Meetup

弊社榊原がモデレータとなり、Japanese Industry Meetupが開催されました。主にCSS WGのメンバーと、日本語組版やデザインに関わっているもののW3C/標準化には関わっていない日本人とで話す機会を設けるものです。こちらのレポートも機会があれば後ほど掲載したいと思います。

月・火の議題ピックアップ

10/26(月)と27(火)は、CSS WGに参加しました。いくつか概要を書いてみます。

font-weight-adjust

フォントによって、同じポイント数でも見た目のサイズは微妙に異なります。

システムによってインストールされているフォントは違うため、font-sizeを厳密に指定しても、1番目のフォントがインストールされておらずフォールバックフォントが利用された場合は、見た目上のフォントサイズがずれてしまう可能性があります。

そこでこの問題を解決するために、font-size-adjustプロパティが制定されています[1]。

font-sizeでも同じ問題は発生するため、font-size-adjustのようにfont-weightプロパティでも同じ問題が発生するため、font-weight-adjustプロパティが提案されました

しかし、これは@font-faceルールでfont-weightを指定することで同じことができる(フォントプロパティ上は細いが実際は太い場合、@font-faceで太めのfont-weightを指定すれば良い)ため、却下されました。

[1]Editor’s draftが作られたきり更新される気配のないtext-size-adjustプロパティとは関係ない機能なのでご注意ください。

Overflow Alignment

以下のようなHTMLがあったとします。

<div style="display:flex; justify-content: center;">
  <p>コンテンツA</p>
  <p>コンテンツB</p>
</div>

これは改行しないflexなので、もしコンテンツが大きかったりたくさんあると、あふれます。center指定してあるので、左右に均等にoverflowすることになります。

もしこのflex container (親div)が画面の左端に配置していたらどうなるでしょうか?画面の外まではみ出してしまいます。これでは、仮にoverflow: visibleしていても見ることができません。

そこで、「center配置するが、もしはみ出るようならstart配置にする」というのを実現する機能が safeです。画面内側にはみ出れば、読めないよりはましです(スクロール等の対策も可能になります)。
trueはoverflowしても気にせず指定したcenterのままにします。

align-content: safe center;

この機能について、以下のような点が議論されました。

どこまで適用すべきか

text-alignなどにも適用することを視野に入れつつ、現在のところはまずflex/gridでということになるようです。

safe/trueどちらをデフォルトとすべきか

trueがデフォルトとなりました。指定を忘れるとはみ出る可能性があるものの、safeがデフォルトではかえってわかりづらいという意見が大半でした。

プロパティ粒度やネーミングはどうか

機能自体に関しては、十分良いだろうというところで大きな反対はありませんでした。trueがデフォルトなのだからtrueを削除してはどうかという声もありましたが、両方維持になりました。
ネーミングについては、”true”がやや微妙なので、より良い名前が募集されています。

Wide gamut

Webは長らくsRGBのみを対象にしてきましたが、広色域ディスプレイも普及し、Adobe RGBなどより広い色域への対応が本格的に検討されています。

  • タグなし画像はsRGBと仮定するのが現実的で安定するため、 color-correctionプロパティは削除されました。
  • タグ付き画像はそのタグに従えば良いですが、色番号指定も広色域に対応すべきです。background-color: rgb("adobe rgb", 0, 0, 255);のような形で指定するのが良いのか、アルファ付き4引数と混ざるためicc-colorのような専用のキーワードを追加するか、@ruleのような書式にすべきか、などが議論されましたが、その場で結論は出ず、Editorが提案を作成することになりました。

Scroll snap

Issueリストに従って1つずつ検討されました。

Scroll snapの仕様を把握していないうえに内容が多く把握しきれなかったので、詳細はIRCをご覧ください;;

MS EdgeとSafariで挙動が違う部分をどちらにすべきか、なども話し合われていたようです。

続く

CSS WGだけで2日間がっつりやっているため、まだまだ内容はあります。
後ほど続きを更新予定です。

TPAC 2015 報告前半(榊原バージョン)

$
0
0

BPS 榊原です.

10/25 〜 10/30 @ 札幌 で開催されていた TPAC 2015 に参加してきました.BPS は W3C の会員企業です!

CSS WG や DPUB IG などにおける技術的なブログに関しては,弊社馬場よりアップされるかと思うので,僕の方はマネージ的な立場からの TPAC について備忘録を残しておこうと思います.写真は気が向いたら追加します.

北海道からの機内が暇なので書いたというわけではありません.

TPAC2015 概要

W3C には HTML や CSS,WoT などさまざまな領域における標準化活動を行なっているグループがあり,それぞれのグループが個別に F2F ミーティング (Face to Face/直接のミーティング) や ML での活動を続けています.ただし,全て個別で進めていては,ウェブとしての連携もとれなくなってしまうので,年 1 回,TPAC という名称で全体会議を行なっています.

基調講演などがあったりしますが,実態は,各グループの F2F の集合体です.

BPS は超縦書という EPUB3 ビューア製品を開発しているので,関連するのは,CSS WG,DPUB IG (Digital Publishing Interest Group),Houdini TF (Task Force) あたりです.

昨年の TPAC 2014 @ Santa Clara の時点よりも,CSS や電子出版における技術的な問題がどこなのか,また,その問題を日本からどのように発信するべきなのか,についてのノウハウが溜ってきたので,昨年よりもかなり活発に W3C内において活動することが出来ました.

10/25 (日)Japanese Industry Meetup

本会議は,正確には W3C のミーティングではなく,BPS が主に取りまとめる形で,CSS WG の方々と,日本の出版・ウェブ業界の方々とお話をする機会としてセッティングしました.

Techracho においてご報告していませんが,実は榊原は,前回の CSS F2F ミーティング @ パリ に参加していました.EPUB3 及びウェブにおける縦書きはwriting-modes module という CSS module において仕様定義されているのですが,10 年以上たっても勧告に至っていません.W3C において勧告に至るためには,WG 内で勧告の必要性が認知された時点で,参加メンバたちがアクティブに動き始めます.よって,writing-mode の勧告が必要だ,と騒ぎに行ったわけです.

WG メンバとのご飯会や初めての F2F での発言などを経たところで,うっかり「日本人は英語苦手だし,意見はたくさん持ってるけど WG に来てまで喋るのは無理だよ HA HA HA」*1 と言ったところ,「じゃあ,日本語主体で良いからら,日本内の興味ある人集めて,縦書きに限らず,ウェブにおけるレイアウトの会議を開こうぜ!」と切り返されました.このとき,「OK,俺がやってやんよ」と言うことで,主催することになりました.

*1 僕はあまり喋れないです.こんな気持ちで英単語を並べた,と想像して頂ければと思います.

会場のセッティングやら業界に関係しそうな方へのお声がけをさせて頂き,上記リンクの通りのメンバで実施となりました.CSS WG からは 15 名くらい,日本からは 20 名くらい参加して,会話を進めてみました.

会議体としては,英語/日本語がわかる Florian が主に会議の内容を WG メンバ側に伝えつつ,基本的に日本語で会議をしてみました.

本来,wiki に書いているような内容の話をしようと思ったのですが,なにげに一つのトピックが長引き,3 時間はあっという間に過ぎてしまいました.Florian からは 1 日会議をしよう!と言われていたのに,3 時間にしてしまったのが,多少悔やまれます.次回は,1 日近く行なってもいいかな?なんて思ったり.

会議の後に,食事会も設定したところ,会議中はあまり発言の機会が得られなかった参加者の方が,積極的に WG メンバと話をしていたのを見て,とりあえず第一段としては,OK かなと安心しています.現在,CSS WG に対しては,F2F を日本でやろうぜ,と話していて,2017 年一発目の F2F は日本でできそうな流れです.それまでに,国内の出版社や組版エンジンを作られている方など,関係する方々に声をかけさて頂きたいな,と思っています.

ちなみに本 Meetup 内では,組版的な要望について BCCKS の田中さんからの意見で話が進み,JLReq に対応する CSS 仕様をどこまで定めれば良いのか,また,ブラウザ側が実装すれば良いのかが分からない,という意見がありました.これについては,日本側から意見が出せればな,と思ってます.

さらにちなみに,可能なら日本からの意見は取りまとめる必要はないな,とも思っています.BPS からの意見,別の出版社様からの意見が,WG において多少ぶつかっても,議論と言うことで周りと考えていけるような状況になれば最高だな,と思ってます.

10/26 (月)

TPAC 初日です.CSS F2F がメインで行なわれつつ,夕方から Developer Meetup というものが開催されていました.

CSS F2F の議論詳細は馬場の記事を参考にしてもらえればと思いますが,Scroll Snap の議論をしている延長で,physical/logical の命名に対し,どのように Scroll Snap が対応するべきか,という議論が活発に行なわれていました.physical/logical 問題は,writing-modes module にも深く関わってくる議論なので,後ほど僕も復習しておこうと思っています.

Developer Meetup では,何件か発表が行なわれていました.

Service Workerという,ブラウザ上で動作する proxy のようなものが発表されていたのですが,なぜウェブ上でこのようなものを再実装するのかなー,というのは実は理解してないです.似たようなもの,他にもたくさんあるんじゃね…など.

Mozilla からは,SFC 時代の同期の工藤君による CHIRIMEN デバイス及びそのソフトウェアアーキテクチャの紹介が行なわれていました.回路設計がオープンソースになっているそうなので,興味のある方は,基盤実装をしてくれる会社に持ち込めば,自分の基盤を作れるんだぜ!とか,IoT/WoT のソフトウェアレイヤリングはこうなるぜ!などの紹介をしていました.

ということで,初日は終了.

10/27 (火)

続 CSS F2F.

どうも札幌コンベンションセンターに設置されているプロジェクタと,Mac 向け RGBmini Display Port 変換器の相性が悪いらしく,議長(Alan) の Macでもろもろ情報が映せません.一緒に見てたら,「もう面倒だから,お前のPC (Thinkpad) で表示しておいてくれない?」ということになってしまい,会議を途中で抜けて内職することが出来なくなりました….

Rounded Display という丸いディスプレイに対する CSS 仕様が韓国 LG さんから提案されています.どうも腕時計を作りたいみたいっすね.彼らが偉いのは,ちゃんと仕様を自分たちで書いて,少しずつ押し進めているところです.英語力は僕達と変わらない感じなので,発表するたびに,ぼっこぼこにされていますが,めげずに持ってきていて,ちゃんと先に進んでいます.

脱線しますが,CSS WG では,チャットシステムとして IRC という太古の時代のツールを使っています.ただし,結構システム化もされていて,議論中にACTION: などと書いて発言すると,bot がその発言を拾い TODO 化してくれます.仕様における issue が解決した時は RESOLVE: とかですね.

Rounded Display に話を戻すと,LG からの担当者はちょいちょい WG メンバからの要求を聞きとれていないらしく,「もう IRC で ACTION 作っておくから後で確認してね」ということで,ものすごい勢いで ACTION を積みまくられたりもしています.でも,ちゃんと ACTION にまでしてくれるのは,優しさな気がするので,もし僕らが何か持っていってぼこぼこにされたとしても,どうにかして伝えようとしてくれそうなので,そこは安心です.

この話をしている最中,どうもディスプレイの形は正円または楕円しかないのか?という議論になりました.「今後星型のディスプレイとかでるかもしれないじゃん!」「いやいや…現実を見てみろよ,そんなのは存在しないだろう?仕様として必要ないYO!」などと話をしているところで,まず,僕の方からたまごっちを IRC 上で紹介してみました.すると,「ほうほう,楕円は可能性があるかもな」となったところで,任天堂の変態ディスプレイが,弊社と今回共同で参加してくれたユニバ株式会社の今野さんから投下されると,場が荒れ始めます.

・匿名希望さん:「ほら,こんなディスプレイがあるんだから,Rounded Display はもっといろんな形に対応した方が良い気がするんだ!」
・ブラウザベンダーG:「俺はこんなディスプレイ向けの実装はしたくない!」

15 〜 20 分はこれだけで議論していて,笑いながら聞いていましたが,僕らとしても,燃料を投下しただけで,現段階で本気で検討して欲しいわけではないので,そっと画面表示を任天堂のディスプレイから,IRC ログに戻したところ,議長(Rossen) から,「おい,さっきのディスプレイに戻してくれ」との指示が.かなり気に入られたようです.

この他にも,現状提案されているスペック一覧を見ながら,メンテされていない仕様を消そう,という提案が出た際は,各仕様の Editor たちがピリっとしはじめていました.

こんな感じで二日目の CSS F2F は終了.(もちろん,他にもたくさんのトピックがありました)


W3C には AC (Advisory Committee) という人が,各組織に一人います.組織を代表する人,という意味です.新たな WG の設立や技術方針について話をする際に,投票権を持っているのです.

現状,BPS の AC は榊原です.が,まだ W3C の中の全てのことにまで手を広げる余裕はないので,あまり興味は持っていません.その AC が一同に会してご飯を食べる,AC dinner が火曜日の夕方に計画されていました.興味もないので,今回一緒に参加しているみんなとご飯を食べに行こうと思っていたところ,W3C/慶應の中村修さんから「えー,行こうぜ」との声がかかり行くことに.ちなみに,中村修さんは学生時代の僕の先生の一人なので,指令に対しては YES または はい しか答えられません.

AC の知合いも少ないので,中村さんにくっついてご飯をゆっくり食べるか,と思っていたところ,村井先生と一緒に移動しつつ,妙に威厳のある人々が多い席にきてしまいました.ERCIM のトップらしい人が目の前に座っています.また,左に大きなおじさんがいるので,聞いてみたところ HTML5 WG のco-chair だと言っています.もちろんご飯の味はあまりしませんでした.

AC dinner はジンギスカン.運営側は,一つの鍋をみんなで箸でつつく,というのがちゃんとワークするのか少し不安だったようですが,特に問題なく,外国の人々はお肉を食べまくっていました.

ご飯の最中にも,ミーティング設定を急きょすることになり走り回ってました.この時,DPUB の Ivan さんという議長?さんと,Willey という会社の女性の方(多分この人も DPUB の偉い人)と挨拶しつつ,DPUB へのスムーズな joinができるようになったので,どうにか良かった気がします.

無事 AC dinner を乗り切った後は,村井先生,中村さん,などなどと別でご飯に….禁則事項が多いようです.

ということで,二日目終了.気を使うことがなにげに多いです.

10/28 (水)

水曜日は Plenary Day.まだ WG や IG になっていないトピックについて話し合うための時間や,会議に参加してくれた人全員に向けた食事会が開催される日です.

(ブログ記事的には)残念ながら,15 時から道内で TPAC とは関係のないミーティングがあったため,榊原は少しだけの参加となりました.

個人的に Houdini という新しい技術が気になっています.こちらは,ブラウザ内で保持されているレイアウトに関する詳細な情報を,Javascript から取得・変更できるようにしよう,という技術です.例えば,現在のブラウザのアーキテクチャでは,フォントはブラウザによって読み込まれ解釈されるだけで,フォントの持つプロポーショナルか等幅か(さらにもっと細かい情報)などの情報をウェブ制作者は取得・利用することはできません.Houdini はこの情報を取得できる API をブラウザに実装しよう,というものです.Google, Apple, MS, Mozilla の主要なブラウザベンダは,皆さん技術者が参加していて,API を決定しようとしています.

この技術があると,現在の CSS では,プロパティが定めたレイアウトでしか,文字などを表現できないですが,微調整をすることが用意になるはずです.ルビの位置の微調整などですね(注:ただし,微調整が出来るようになるまでは,まだかなりの時間がかかると思われるので,もう少し CSS としての仕様化というのは大事なプロセスだと思います.).また,Houdini のような話が進むことで,ブラウザアーキテクチャの見直しにつながれば,とも思っていますが,まだ,僕も分かっていないところが多いので,もう少し勉強したところで書かせて頂きたいと思います.

さて,この Houdini の unofficial 会議が開催されている,ということで,少し遅れて合流しようと,馬場の指定する場所に向かうと,ロビーのような場所に,3, 4 人の人が集まって,一心不乱に作業をしています.良く見てみると,Google と Adobe の人達が,Houdini 向けの仕様ドラフトを書いたり,デモを作ったりしています.ただ,一心不乱過ぎて,会話がめちゃめちゃ早いです.エスパーしても理解できないくらいの速度です.仕方ないので,5 分だけ時間を貰って,どうやれば Houdini 情報をもらえるのか,及び,デモのパッチのありかについての情報を頂きました.欲しい情報を明確に伝えると,にこにこと教えてくれるので嬉しいです.馬場も,パッチをもらえてにこにこしていました(正確には,どこで最新の活動をしているのかが簡単に分かったので,ですね).

残念ながら,ここで僕は退場です.この日は別の作業があったのでした.

木曜日,金曜日の動きについては,また別の記事にさせて頂きたいと思います.

TPAC 2015 報告後半(榊原バージョン)

$
0
0

榊原です.

TCAC 2015 報告の続編です.

読んでくれた人から,「完全にただの日記ですね」と言われましたが,はい,出来るだけ会場の雰囲気を届けたいので,日記形式でお届けしています.

10/29(木)

TPAC 後半戦です.後半の(個人的な)目玉は,DPUB IG (Digital Publishing Interest Group) と houdini TF (Task Force) です.ネットワークなどの研究をかじっていた身としては,houdini の方が実は興味津々です.houdini は,単に CSS のfragment にたいしてアクセス出来る API の穴をブラウザに開ける,というだけに留まらず,ブラウザのアーキテクチャをもっとアクセスしやすいようにする,という副次的な効果があるのでは,と考えています.現在のブラウザは,HTTP という通信機能や WebRTC のようなマルチメディア的な機能,CSS のような自動組版機能など,多くの機能を持っています.持ち過ぎています.確かに現在のさまざまなシステムは Web/HTTP を中心に回っていますが,それを受けとるソフトウェアであるブラウザは,肥大化しすぎていると思います.OS の kernel も似たような議論があって,micro kernel とか monolithic kernel とかの議論がありつつも,kernel module というものが登場しながら,monolithic な形を維持しています.さて,ブラウザは今のままで良いのだろうか.EPUB3 ビューアを製品として作ってみた感想として,ぶっちゃけ使いにくいっす.この使いにくさを,API を作りまくることを通して,変化が起きたりしないのかな,という意味でも,houdini の動きには興味があるのです.

とはいえ,本業が EPUB を使った電子書籍ビューアの販売なので,DPUB IG の会議に参加しました.DPUB IG では,EPUB 3.1 という,次の EPUB の仕様についての話が活発にされていました.HTML5 記法を許すかどうか,コンテナーはどうしようか,など話しています…が,僕の事前勉強が足りず,分からないことが多いです.日本の中では,村田さんという方が大きく反対されているそうですが,少なくとも DPUB IG ではその意見が反映された発言はありませんでした.国内で大きな声で話をしてもあまり仕様には反映されない感じです.もう少しお話が聞きたいところです.

CSS WG でも活発に活動している Daniel Glazman という方が POM (Publication Object Model) という話をしていました.BPS の超縦書でも「書籍」を抽象化するレイヤを作成していたので,ちょっと興味が湧きました.どうも,僕達がやったのと同じように書籍を抽象化するライブラリを作りたいようです.ただし,W3C は Web における仕様を策定していく団体です.ライブラリの提案では,なにか違和感を感じます.とはいえ,こういう抽象化レイヤの話は好きなので,どのように今後動いていくのウォッチしていこうかと思ってます.

また,Service Worker (SW) を提案した人が,DPUB に乗り込んできて,「SWは書籍にも有用だろ!使えYO!」と叫んでいました.…ふむふむ.Web 上にProxy を実装するようなものをどうやって書籍に適用するんだろう? EPUB の中に SW を入れるのかな…?など考えていると,どう考えても違和感しかないです.EPUB とかをキャッシュしたいなら,ブラウザの外で proxy server でも建てればよい話だし,EPUB の中でそんな変なものが動かれても,ダウンロードとの絡みが意味不明になってしまいます.とりあえず,電子書籍と SW の親和性は低そうに見えます.業界からの要望に応じて,適切なソフトウェア設計をして頂きたい.ただ,議論の波に乗っかって文句をぶつけるほどの英語力はないし,そこまで重要なコメントでもなかったので,IRC 上で /me とつけて文句をつらつら書いておいてみました.public なコメントにならないはず!と思っていましたが,議長さんは見逃さず「skk ってやつが何か言ってる.喋れ」とマイクが回ってきてしまったので,とりあえず文句を言いまくってみました.その後,別の議長さんが,ネットワークファイルの透過性の話と設計を絡めて似たような話をしていたので,大はずれではなかったはず.ちなみに僕の英語力だと,前述の通り,議論の波に乗っての発言は出来ません.日本語でも複数人で会話している際は,話の流れに沿ったタイミングと話の速度で発言しているはずです.英語でも同じです.それが出来ない場合は,挙手するなり,IRC に q+ と書き込むなりして自分の時間を確保した上で話をしています.おかしなことを言わなければ,ゆっくり話しても嫌な顔はされない空気感なので,是非発言していきましょう.

ということをしているうちに,木曜日の会議は終了.夕飯は,JP Industry Meetup を裏で支えてくれていた人との会食.色々な話をしつつ,楽しい時間を過ごさせて頂きました.

10/30(金)

TPAC 最終日.

どうも,AC dinner の時に設定した,パワーランチ(笑)が存在していたようです.ただ,僕がメールを確認したタイミングでは,何もなさそうな雰囲気だったのと,連日の夜の会食の疲れがたまっていて,「今日は寝ます!」と馬場に伝えて,会議をすっぽかしてホテルで寝ていました.昼過ぎに起きたところ,電話の履歴がひどいことに.はー.頑張って設定したのに,出られないとかマジしょんぼりです.しかも,会議もほとんど聞いていないので,何の話をしていたのかさっぱり分からず.何をしていたんだか…

と,何も仕事はしていないにも関わらず,懇意にしている vivliostyle さんが設定してくれた,vivliostyle friends の夕食会に参加です.日本人は,vivliostyle の村上さん,村上さんの奥様,馬場,榊原,のみで,残りは,DPUB などで活発に活動されている方々ばかり.トータルで 10 名程度でご飯です.Richard Ishida さん,Dave Cremer さん,Alan さん,Florian さん,台湾の Bobbyさん,Chris さん,などなど業界有名人だらけ.もう慣れました.

Houdini ってどこ目指しているのよ,とか,日本国内出版社とのつながりをもっと深くしようよ,とか,色々な話が出来ました.こういう話を通じて,最終的に電子書籍の市場がでかくなってくれると嬉しいですねー.

ということで,TPAC 最終日終了.最終日は電池切れであまりかつ度してませんでしたが,おつかれさまでした.

10/31(土)

番外編.

土曜日の夕方の便で帰ることになっていたので,ホテルをチェックアウトしてから,弊社馬場と多少は札幌内をうろうろしようかということに.ただし馬場は観光には興味ありません.

・「時計台見に行く?」
・「興味ないです」
・「北大散策する?」
・「別に」

むむむ.ふと,ホテルの机の上を眺めていたら,場外市場のパンフレットが.

・「カニとか食べるか?」
・「行きましょう」

ということで,電車を乗り継ぎ場外市場へ.ちなみに,今回の移動手段は一緒に宿泊していた人数が多かったこともあり,タクシーが多かったです.よって,ホテルの周りに何があるかすら,ほとんど知りませんでした.少し歩いてみると,コインランドリーやクリーニング店が散見されます.僕と馬場は,宿泊日数が多かったこともあり,ホテルのラウンドリーサービスを利用したのですが,通常の 2, 3 倍はします.外に出てみて少しげんなりしてしまいました.長期出張の場合こそ,前日入りして,生活情報を集めるのも大事かもしれないですね.

さて,場外市場は観光地と言うこともあり,カニ・いくら・うになどの文字が踊っています.適当に見繕った店(海鮮物屋さん併設の食事処)に入り,いくら・うに丼を食べようとしたところ,店先で売っているカニも食べられるとのこと.これは食べるしかないね,ということで外に見に行ってみると,タラバだのなんだのをとにかく試食させてきます.むむむ.もう食べるしかないじゃんね.ということで,毛ガニを行かせて頂きました.また,待っている間に馬場が「ホタテバター焼きも!」と珍しく追加オーダーをしています.僕は,会食に近い形で色々なところで食べていましたが,馬場はあまり外に出ていなかったので,特に食べたかったようです.出張を通して最高の笑顔で食べていたのが,印象的でした.

満腹になったところで,今回は余裕を持って空港に行き,出張は終了です.

ご迷惑・お世話をかけた皆様,どうもありがとうございました.引続き色々な活動をしていけたら幸いです.

縦書きWebデザインアワード

$
0
0

縦書きウェブの普及

みなさん、縦書きのウェブページ、よく見かけますか? ロゴやボタンやメニューが縦書き、というページはたまに見かけることがあると思いますが、サイト全体が縦書きでレイアウトされているページは、まだまだレアなんじゃないかと思います。

縦書き推しのBPSとしては、小説、雑誌、街の看板など至るところに縦書きがある日本では、ウェブページも、横にまみれず縦にいったらいいな、と日々思っています。最近、Firefoxでも縦書きがうまく表示されるようになったようですので、このページも様々なブラウザできちんと縦になっていることでしょう。

そんな折、縦書きウェブ普及委員会のページが開設されました。
http://tategaki.github.io/

screencapture-tategaki-github-io-1447666956294

素晴らしいことに、縦書きでメインのコンテンツが制作されています。やっぱり、縦書きって、ピリっとした感じだったり、暖かみがあったり、これぞ日本っていう感じがあったりと、読んでいると落ち着く気がします。気のせいでしょうか? (ウインドウ幅が小さいときは横書きになる仕組みのようですので、モバイルでは横書き表示かもしれません。)

縦書きウェブデザインアワード

縦書きを利用したウェブコンテンツの普及促進として、デザインアワードが開催されます。募集ページはこちらです。
http://tategaki.github.io/awards/

BPSはこうしたCSSの普及活動に積極的に関わっていて、ここでもサンプル作成や仕様解説などで協力しています。

ブラウザ側の対応は、おおかた出来ています。あとは、いろんな方面で、せっかく整備された縦書き機能を生かした、縦書きのウェブページの制作が進むこと。これが私達日本人の願いです。ちょっと大袈裟ですが。

アワードの開催期間は201511月~20163月で、3種類の部門があります。みなさん奮ってご参加ください。

漫画翻訳のナンバリング作業時間を大幅に短縮するウェブツール、ようやく紹介資料ができました

$
0
0

こんにちは。BPSの渡辺です。いつもTechRachoをご覧頂いている読者の皆さま、いつも本当にありがとうございます。弊社漫画翻訳事業メンバーがいつのまにか開発して取引先に導入してたウェブツールの紹介をさせていただきます。忙しくて紹介ページも作ってなかったみたいなので。。本当はもっとちゃんとしたWEBページを作成したいのですが、皆の時間をさらにとっちゃうので、今年度内は取り急ぎTechRacho記事で紹介ページの代用とさせていただきます。ご興味をもっていただいた方はぜひ導入方法や金額や導入実績について弊社ホームページよりお問い合わせください。

ナンバリング特化サービス Nunba Lumba(ナンバルンバ)

ナンバリングとは

ナンバリングは、漫画を翻訳したりや写植するときに使う仕組みで、新たに翻訳したテキストに該当するセリフはどこか?を明らかにするための作業です。これを行うと、写植の作業者が翻訳前と翻訳後の両方の言語を理解していなくても間違ったところに翻訳したセリフを配置しなくなる、というメリットがあります。

ナンバリングの問題点

従来のナンバリング作業では、エクセルなどで翻訳前の台詞をわざわざ文字起こしをし、画像ファイルを開きPDF等にして番号をつけ、その後に再度エクセルに翻訳テキストをセリフのとなりに打ち込んでいくというものでした。まずエクセルですとスペルチェックが行われないためスペルや構文の誤りを目視で確認することが難しく、ミスが発生する原因になります。次に、元言語も翻訳後の言語も扱えない作業者がテキストを配置するときに、文字起こしされているとはいえそもそも認識できないため、ミスが起こりやすい状況でした。

Nunba Lumba(ナンバルンバ)とは

Nunba Lumba(ナンバルンバ)は、弊社の翻訳・写植作業者の声で生まれたシステムです。
クリック一つでナンバリングでき、ナンバリングされた画像データと同時にその番号リストを作成してくれるので文字起こしの作業をなくします。視覚的にセリフに番号をつけるだけでなく、システムで完全に一致した番号リストが作成できる仕組みなため、手作業でのナンバリング作業で発生するミス(画像とテキストで番号がズレたり)が起きにくくなります。加えて作業速度が早まり、かつ、複数の言語で何度もナンバリングし直す必要がなくなり、効率面でもコスト面でも強い見方になってくれます。

ナンバリング特化サービス Nunba Lumba(ナンバルンバ)のご紹介資料

漫画-写植-ナンバリング_ページ_01

漫画-写植-ナンバリング_ページ_02

漫画-写植-ナンバリング_ページ_03

漫画-写植-ナンバリング_ページ_04

漫画-写植-ナンバリング_ページ_05

漫画-写植-ナンバリング_ページ_06

漫画-写植-ナンバリング_ページ_07

漫画-写植-ナンバリング_ページ_08

漫画-写植-ナンバリング_ページ_09

漫画-写植-ナンバリング_ページ_10

漫画-写植-ナンバリング_ページ_11

漫画-写植-ナンバリング_ページ_12

 

 

漫画-写植-ナンバリング_ページ_15

ナンバリング特化サービス Nunba Lumba(ナンバルンバ)についてのお問い合わせ

ご興味をもっていただいた方はぜひ弊社ホームページよりお問い合わせください。ここまでご覧いただき、誠にありがとうございます。今後ともBPS株式会社をよろしくお願い申し上げます。これ以降のコンテンツは、検索エンジンを使ってナンバルンバのようなシステムを求められているお客様が無事弊社ページにたどり着けるよう資料を文字起こししただけです。弊社商材およびTechRachoをご覧いただき重ね重ねお礼申し上げます。

漫画翻訳写植のためのナンバリングシステム「ナンバルンバ」資料の文字起こし

ナンバリング特化サービス Nunba Lumbaのご紹介
BPS株式会社
ビヨンド・パースペクティブ・ソリューションズ株式会社

Numba Lumba3つの特徴
スピーディにナンバリング!
で誰でもすぐに使える!
完成データはでPDFとcsvに!

ドラッグで囲うと赤線枠付きナンバリング!
ダブルクリックでその場にナンバリング!
※赤枠無し
慣れれば約10秒で、
左図ページのナンバリング作業完了!
スピーディにナンバリング!
ナンバリング作業の効率化に!

ファイル
解凍
セットアップ
ID設定などなど
利用開始!
DL
面倒なセットアップは一切不要!
URLにアクセス
利用開始!
URLアクセスで利用開始。操作も簡単!
で誰でもすぐに使える!

PDF
画像
csv
ページ単位の画像ファイルを1つのPDFやcsvにして掃き出し可能!
一斉読込
PDF出力
csv出力
完成データはでPDFとcsvに!
番号漏れ、リストし忘れなどのミスをシステム的に防ぐ!
Numba Lumba

Numba Lumba利用マニュアル
①各自のPCで指定のURLにアクセスします。
Google Chromeでの使用を推奨しています。
他のブラウザだと正常に動作しない、又は動作が遅くなる場合がございます。
URLは契約後に発行いたします。
この画面が表示されれば①は完了です。

Numba Lumba利用マニュアル
②画像ファイルが以下を満たしていることを確認し、対応ページのデータをブラウザ上にドラッグ&ドロップします。
ファイルの拡張子が[.jpg .jpeg .png]であること
ファイル名がページ番号のみになっていること ※例:1.jpg 2.jpg 0003.png 0004.tiff など
画像をすべて選択し、ブラウザ上にドラッグ&ドロップします。

Numba Lumba利用マニュアル
③画像がブラウザ上に表示されていることを確認します。
各画像の左上にファイル名が表示されます。
画像が表示されない時は・・・?
・ファイル名や拡張子が正しいかを確認してください→②に戻る
・ファイルの数によっては表示に時間がかかる場合がございます。最大20秒ほどお待ちください。

Numba Lumba利用マニュアル
④コミックIDを半角英数字で入力します。
最終的に出力されるファイル名は
[コミックID].pdf・[コミックID].csv
となります。
空白のままでも作業は可能ですが、
最終的な出力ファイル名が、
Untitled.pdf・Untitled.csvとなります。

Numba Lumba利用マニュアル
⑤ナンバリング作業を進めていきます。
始点を決めます。
ドラッグで、
テキストを囲います。
ファイル名+-1(番号)が振られます。
・クリック2回でもナンバリング可能です。
・始点は上下左右どこでも選べます。
※ナンバーの位置は始点の位置で決定します。
・ダブルクリックで、その場ナンバリングができます。
※赤枠は付きません。
・右クリックで直前のナンバリングをキャンセルできます。

Numba Lumba利用マニュアル
⑥作業ファイルを出力します。
ボタンクリックでファイルが生成され、各自のPCにダウンロードされます。
コミックIDが入力されているか、PCダウンロード先はどこになっているのか、確認のちにファイル生成を行ってください。
csvファイル
PDFファイル

ブラウザ上部の[更新]( )を押してデータをリセットしてください。
という画面が出ますが、[このページを再読み込み]を押してください。
Numba Lumba利用マニュアル
⑦作業を終了または、新規ファイルを読み込みます。
作業を終了する場合
続けて別のファイルで作業を進める場合
そのままブラウザの[閉じる]ボタン(×)でブラウザを閉じてください。

対応環境・スペック・注意事項
■動作環境 – Chrome for Windows / Mac最新版で良好に動作します。 – Safari、Internet Explorerは動きますが非推奨です。ドロップでの画像の読込みに失敗することがあり、成功するまで、再度ドロップを試みる必要があります。 – Firefoxは非対応です。
■ファイルタイプ 下記の拡張子のファイルが読込めます。 .jpg .jpeg .png
■ファイル名 ページ番号のみがファイル名になっている必要があります。
■画像サイズ 画像のサイズは、どんなサイズの画像も、横850px、縦1200pxに変換に変換してから使用されます。 著しく大きなサイズの画像は、事前に横850px程度または縦1200px程度にしてからドロップすることを推奨します。
■制限事項 画像サイズが大きいと、待ち時間があり、15秒くらい操作できないことがあります。 Safari、Internet Explorerでは画像の読込みに失敗することがあります。成功するまで再度ドロップを試みてください。

error: reference to ‘random_access_iterator_tag’ is ambiguous

$
0
0

メモ:

GCC (not Clang) とlibc++な環境で、boost/unordered_mapを使うとこのエラーが出る。(boost 1.59)

boost/move/detail/iterator_traits.hpp:72:12:
error: reference to 'random_access_iterator_tag' is ambiguous

たとえばChromium Androidはlibc++とGCC4.9。

リポジトリではそのままのエラー修正が既にされているので、1.60を待てない場合はこのファイルだけ新しいものを持ってくれば直る。
https://github.com/boostorg/move/commit/172d49cf5464be290282e12df927571ac3a8ec66

最新ではついでにリファクタされてたので依存ファイルも忘れずに。

要するにlibc++だとstd::__1に実体を定義してusingしているということを初めて知った。

ちなみにFreeBSDだとこんな解決方法らしいけど…

エンジニア20名の会社で何人もエンジニアのインターンを受け入れてみて学んだこと

$
0
0

こんにちは。BPSという20名ちょいのエンジニア主体の会社で、エンジニアリング”じゃない”業務を主に担当している渡辺です。日本語の練習を兼ねてブログを書いていたのが、割と本心で書くとえらく拡散していただいたり、批判をいただいたりするので、恥ずかしくて最近はおとなしくしてました。長男がお受験をしてたこともあり、私の名前を検索したときに変なものがでてこないようにしてました。でもそれ終わり、再開します。会社の皆にもTechRachoを更新してほしくてお願いしているので、まずは僕から再開してみようかと思っています。今回はエンジニアのインターン生、そしてインターンシップについて考えをまとめます。自分向けのログみたいなものですが、これからインターン受け入れしてみようかな、と思っている開発会社にとって多少の参考になれば幸いです。

近年のインターンシップ

過去のインターン生

採用したいけれど大手メディアに掲載するほどの資金力も有効活用できるほどの知名度もないので、成果報酬型の採用メディアとインターンシップを組み合わせている企業さんも多いのではないでしょうか。インターンシップは本来採用とは関係ないものだ!と最近聞いたり読んだりします。でも語源や言葉の定義なんて本質ではないのでどうでもいいです。採用に繋げられるなど何かしらのメリットがあるから企業はインターンシップを試みるし、それを斡旋する業者も、ぜひ採用につなげてください!応援します!応援費をください!と言うので、いまや企業にとってインターンシップは採用手段の一つです。学生にとっても、就活時に周りと差をつける手段の一つです。とはいえ、最近だとインターンしていない学生のほうが稀なので、むしろ学校にこもってひたすら勉強している学生のほうが希少価値があるかもしれませんね。どうせ社会にでれば実務経験は得られるし、最近のインターンシップは採用や広報を兼ねているせいか実務経験の辛い部分は浮き彫りにならない仕組みで運用されてますし少しずつ考え方を時代にあわせてシフトさせていくべき頃かもしれません。ちなみに以下が弊社が打ち出しているエンジニアのインターンのメリットです。

エンジニアインターンシップのメリット

そんな時代背景の中、インターン生にはいきなりOJTといって現場に放り込んで一緒に試行錯誤する方針(笑)の弊社には、だいたい月に1-4名程度のインターンシップ応募があります。以前からお世話になっている大学の研修室からご紹介頂くケース、TechRachoを見てく興味をもってくださったケース、インターンシップを紹介するメディア経由で応募していただくケースと、様々です。応募数だけをとれば、会社規模の割に多いほうなのではないでしょうか。感じたことをまとめていきます。

エンジニアのインターン生の種類

エンジニアではなく、エンジニアになってみたいインターン

これまで何かを開発した経験やプログラムを勉強してきたわけではなく、これから勉強したいという学生さんが多いですね。弊社だと、だいたい応募者の約三割がこれです。学校で勉強していても社会でどういうふうに技術が使われるのかいまいちわからない、勉強だけだとお金をもらえないからバイトをかねてやってみたい、開発する学部じゃないのでもっと本格的にやってみたい、ではなく、弊社にきて初めてプログラムを書いてみたいという学生さんです。企業側はインターンシップから採用に繋げたく、学生はスキルアップを目標に来てくれているので、多少の歩み寄りは必要です。といっても、独学でやるのとさほど内容はかわりません。ネットのチュートリアルを進めてもらい詰まったら助けてあげる。それが終わったら昔の案件を掘り出してきて、それを進めてもらう。この程度です。学生さんが悪いとかインターンシップが危険というわけじゃなくて、こういうものだとわかって会社の方針レベルでどう対処すべきかを事前に決めておくとお互いのタイムロスを防げるかと思います。

エンジニアリングは仕事でやると嫌いだと気づいてやめるインターン

多少手を動かした経験があれば、まるで魔法のように開発できる人をみて憧れを感じることは誰にでもありますよね。好き勝手に書いていたプログラムをデザインパターンに合わせてリファクタするならまだしも、既存プログラムの負の遺産や共同開発者の癖にあわせて自由がないことも多々あります。魔法のようにクリエイティブに見えた仕事も、業務内容によっては繰り返しのルーチン作業を伴うこともある。また、業務でエンジニアリングを行うということは、自分のためではなく使ってくれるユーザや企業のために開発するということです。楽しそうだけど無駄な機能はやっぱり作らないという判断もあるし、前に作ったことがあるけどユーザにとって大事であればまた作ることもある。これらに耐えられないインターン生から、エディタと8時間近くにらめっこすることが耐えられないインターン生、先輩をみて才能に自信がなくなるインターン生と、様々です。もともとインターンシップは学生にとって自分の将来探しの側面も兼ねているため、こういうことは多々発生します。これも、インターンシップとはこういうものだと予め覚悟とその後の対応方針をきめてインターン受け入れを始めることをオススメします。

一人で勉強し続けられるほど熱意はなかったので企業側が放置するとやめるインターン

殆どのインターン生がチュートリアル通りに何かをつくってみるところまでは途中退場せず完了させるインターン生が多いとわかりました。手取り足取り何をすべきかをまとめてあるサイトをみながら、そのとおりに手を動かすと、費やした時間のぶんだけ必ず成果がでる。わからないところがあっても大抵ググればどうにかなるし、インターン中ならつまづくところはみんな同じなので、周りもそういう話しを和気あいあいとしながら助けてくれる。自分の成長を実感できる。たしかに、やったことがある、チュートリアルまで完了した、というのは大事な経験ですし、とても大きな第一歩だと思います。自分で頑張ってもみないで遠くからごちゃごちゃ言う人も多いなかで、僕はやってみるという決断をして、チュートリアル完了までやりぬいた人も賞賛されるすべきと思います。ただし、初級の授業を学校で受け終わったレベルにも達していないこともまた事実です。チュートリアルを終えた程度だと当然業務に開発メンバとして参加できるわけでもない、仕事じゃなくても本当に作りたいものが作れるわけじゃない。でもそこから先は作りたいものをある程度自分で決めて作らなければならない。もがくしかない。ここらへんで企業側がチュートリアルのかわりをしっかり指導し始めなければいけないので、手間がふえてちょいちょい手を抜きがちです。頑張ってほしいなーと悠長なことを考えている間に、学生は次のインターン先を探し初めていることがあるのでせっかくの縁を棒に振りたくなければケアが必要です。

まとめ

最近は特にエンジニアは売り手市場なので、エンジニア向けインターンシップを紹介するメディアが増えてますね。週に1回以上は新しい媒体の営業電話を受けます。そのせいか受け入れ側の企業も”次がある”と思って手を抜き、学生さんも同じ思いなのですぐに移る、といった話しを似た規模の開発会社さんからよく聞きます。採用と同じで、人は数撃ちゃあたる戦法はうまくいきませんね。そしてとりあえず採用できればわけでもない。一つ一つの出会いと大切にしつつ、会社としての教育環境向上、そもそもの就業環境向上を目指し、その結果出会いが増えるのが最も自然ですよね。今年のBPSは、それをします。ようやくそれに力をいれられるようになってきたのです。

というわけで(?)

弊社へのお誘いですー♪インターンだけでなく新卒・中途採用もしてまーす!

いままで培った技術を、あなたなら何に使いたいですか?僕らは日本のコンテンツ業界の発展のために使いたい。電子でコンテンツを安全に流通させられないことが市場発展の足枷だと思われていた時代は終わり、次は電子でのコンテンツの”ありかた”について、技術×企画で考えて創っていく必要があります。少しでもこの分野に興味があれば、ぜひ弊社を一度見に来てください。人数や規模のわりに、可能性が大きさに驚いていただけるかと思います。そして以下が入社後の大まかなキュリアマップです。詳しくはぜひ採用ページをご覧ください。

採用後のエンジニアキャリマップ


[CSS][ルビ] CSS研究部Webを更新しました

$
0
0

CSS研究部Webを更新しました。9月に行った勉強会の書き起しです。
今回はPar分けはなく、1本のみです。

* CSS研究部 第三回部会 – New!

本日更新分は、ルビについて扱っています。ルビは日本語に欠かせない表現のひとつです。

group-xo-54682063

440px-Railgun-1.svg-f92d7ab0

今後の予定については、CSS研究部のWikiをご覧ください。

この部会はCSS仕様の先端に切り込もうとしている分、記事に不備が残っているかもしれません。お気付きの点がありましたら、記事の末尾にコメントをいただけると助かります(Disqusを使用しています)。

PASSIONナビと紹介とで3名採用した2016年度新卒入社学生の内定式を開催しました。

$
0
0

先日、11月20日(金)にBPS2016年度新卒生向けの内定式を開催しました。

SONY DSC

新卒3期生となる2016年度卒は3名の入社を予定しており、(他社からの誘惑や本人たちの学校でのヘマが無い限り)4月1日から新しい仲間として一緒に働くことになります。

新卒1期生はBPS設立して2年目に採用しているのですが、その時は僕はまだ入社していなかったので、一応人事として面倒を見始めたのは2015年度卒の2名から引き続いて2年連続となります。

とはいえ、エンジニアが9割を占めるBPSでは非エンジニアである僕が教えられることは数少なく、「ご飯をご馳走になったらその場はもちろんメールとかLINEとかで御礼言うと好感度UP」くらいしか教育は出来ません。

仮に、ストレスのもとになっている先輩エンジニアがいる時や仕事を辞めたくて仕方がない時は相談してね、と伝えてはいますが、2015年度卒の新卒2名が入社して8ヶ月、幸いにしていまだそういったクレ・・・いや相談は受けておりません。ようし、このままこのまま・・・
前職が新卒採用のメディアを扱う営業だったこともあり、内定を出して内定承諾を貰っても実際に入社しない場合があることを重々理解しています。
そしてそれを最小限にするためには、新卒の子たちにより多く会社に来る機会を増やしたり、不安を取り除いてあげたり、(本人が望むなら)インターンとして入社までに戦力化を頑張ってもらったり、と4月1日までは気を抜けないなと思っています。

と、言うわけで半ば強引ではありますが、歓迎の意味を込めて少し遅めの内定式を敢行するに至ったのです。(これまでも何度か来てもらったりはしてましたが、案件の打ち上げなど他が主役になる場合が多かったです)

内定式とは言っても、どこかのホールを借りたり全員スーツでビシッと決めたり、なんてことはせず、BPSらしく簡易内定式+社内でのケータリング+2次会で中華料理屋貸し切り、な感じでした。

僕自身が大学中退して、前述の営業会社に中途的な立ち位置で入社したため、内定式とは何をすれば良いのか分からなかったのですが、内定証書を(開始2時間前に)作ったり、会社の権力者から一言ずつありがたいお言葉を貰ったり、最後に写真撮影をしたりとそれっぽい感じには仕上がったのではないかと思います。

そういえば、新人さんには恒例になっているイラスト入りマグカップの贈呈も行いましたよ。今年の3名+先日入社した中途の方のイラストです。

村松くん

剣道やってるらしいので、そのまま剣士に。
普段の姿勢も良いので、直立にしています。

海老原くん
ダーツが趣味だというので、幽遊白書の刃霧っぽい感じ。

田島くん
電機大出身だということで、大学のイメージも併せてメカニックに。

八木さん

中途入社の方のイラスト。
ファンタジー系でもちょい悪系が好みだということで、海賊にしてます。

 

ちなみに、今回はイラストをventryさんにお願いしました。
今も同じ価格か分かりませんが、3,000円/人なので4人で12,000円、それにマグカップ代が1,500円/個だったので、全部で2万円以内でプレゼントを用意できました。

※コップの写真撮ろうとしたら皆持ち帰ってました。気にいってくれた、ということにしておきましょう。

代表が、メッチャカッコいい内定証書に憧れているみたいなので、来年度はなんとか予算をもぎ取って重みのある内定証書を贈呈したいと思います!
そして、式の最後に撮った集合写真です。

 

SONY DSC

さぁ、どのイラストがどれに対応してるでしょう?(1問25点:100点満点)

アルバイトの方やパートナーさんも一緒に撮影しましたが、こうやって見ると人増えましたね。
現在は、中途採用と2017年度の新卒採用に向けて注力しているので、来年の同じ時期にはもっと増えているのではないかと思っています。
簡易的な内定式が終わった後には、皆でケータリングを軽く楽しんで、2次会である中華料理屋に向かいました。
お酒が飲めないメンバも多いBPSなので、せいぜい新卒の学生以外は4~5人残ってるくらいかと思いきや・・・(僕が内定式後のケータリングの後、1件別件で面談が入っていたので遅れての2次会参加だったのです)

SONY DSC
結構盛り上がってる。笑

この日は、パートナーさんからブリが届き、出世魚だし新卒の内定式に縁起もよさそうだよね、というかなり強引なこじつけで、会場の中華料理屋さんに丸ごと料理してもらいました。

さて、そんなBPSは実は新卒3名の他にも入社予定者がおり、2016年4月段階では合計で5名は増員している予定です。(もちろん更なる仲間も募集中です)
IT業界はメンバーの増員が激しい業界ではありますが、今のところ増える予定しかなくて採用担当としては安堵しています。
採用情報については、自社のホームページ、もしくは最近掲載スタートしたGreenさんに詳しく書いているので、もしピンと来た方いらっしゃれば、遠慮なくご連絡ください。

「応募」という堅苦しい意思表示じゃなくても、ちょっと会社見学してみたいとかでも大歓迎です。お応b・・・じゃなかった、ご来社お待ちしております。
読んで頂きありがとうございました!

第7回ネーム大賞に今年も協賛企業として参画いたしました。BPSの漫画翻訳事業について簡単な紹介付です。

$
0
0

ブラックジャックによろしくで有名な佐藤秀峰先生率いる、佐藤漫画研究所主催の第7回ネーム大賞に今年も協賛企業として参加しました。

キャプチャ
・ネーム大賞とは・・・?

 「ネーム大賞」とはネーム(絵コンテや下書きのようなもの)の状態で応募が出来る漫画賞です。
新人漫画家の育成、漫画業界の発展を目的として立ち上げられ、漫画onWebが主催しています。
プロ・アマ問わず漫画のネーム作品をひろく募集して、プロの漫画家や編集者、読者のみなさんによって審査を行い、大賞、準入賞、佳作と、本賞にご賛同頂きました協賛企業のみなさまより頂く特別賞を選出します。

詳しくはこちら
僕が担当になって2年連続で参画していますが、今年も読みごたえのある作品ばかりで、選考にかなり迷いました。

BPSは絶賛運営中のMANGA REBRONと絡めて、ネームの漫画を翻訳+写植する権利を商品に、MANGA REBORN特別賞として2作品選出することができます。
今年は、代表の渡辺と僕の意見を不自然なほど反映してC-004 まおふ〜大魔王のOFF〜 57P 水野まどかA-034 MY SHRED HERO 80P MUSASHIの2作品に特別賞を贈呈させていただきました。

結果はこちらにまとまっています

 

ちなみに、事後報告で申し訳ないのですが去る12月15日にニコニコ生放送で授賞式の様子を放送しており、ちゃっかり私も出てきました。

Pasted image at 2015_12_15 07_58 PM Pasted image at 2015_12_15 08_13 PM

第7回の応募総数はなんと350越え
アマ・プロ問わず誰でも応募できる事から気軽かつ熾烈な選考会になっているみたいです。

作品数も多いので、最終選考に残った10作品は流石でした。ジャンルも様々で非常に楽しかったです。
あくまでもネーム大賞なので、当然ですが仕上がり前の状態です。
そのはずなのですが、それでも引き込まれてしまう作品が多かったのは、やはり作品の切り口やジャンル・ストーリーが斬新だったからなのではないでしょうか。

当日は20時から生放送でした。

Pasted image at 2015_12_15 08_02 PM
協賛企業の皆さまからは、賞金だったりマンガを100冊好きなの選べる権利を貰えたりと、豪華な副賞が目白押しでした。
BPSの漫画翻訳も、毎年贈呈させていただいた漫画家さんには非常に喜んでもらっています。

Pasted image at 2015_12_15 08_05 PM
授賞式の後は、近くのカフェで懇親会。写真 2015-12-15 21 23 57
普段は接することの少ない漫画家さんなどと楽しくお話しさせていただきました!

写真 2015-12-18 15 48 53
これは協賛企業のうちの2社さまが共同で作成した、最終ノミネート10作品を印刷・製本したものです。
授賞式で、賞状と共に漫画家さんに贈られているのを見てうらやましいなーなんて見ていたら、後日きちんと届けてくださいました。
リアル本で読まないと漫画読んだ気にならない!って方は是非、BPSに遊びに来てください。仰っていただければ↑の漫画をお持ちします。(その場で読んでくださいね、くつろげるスペースもございます。)

第8回ネーム大賞にも、協賛企業として参画する予定です。
協賛入りたい!と思っていただける企業さま、是非ご連絡ください。紹介します。
さて、ここからは少し宣伝です。

BPSでは一昨年はじめ(2014年はじめ)頃から、漫画翻訳事業がジワジワと成長しています。
漫画翻訳事業の紹介ページも自社HP内にございますので、是非見て頂けますと幸いです。

2020年の東京オリンピックに向けての動きなのでしょうか、最近日本の漫画を英語や中国語に翻訳してほしいという依頼がかなり増えております。
お問合せの数で言えば、月2~3件はコンスタントに来ている状態です。
複数のコンテンツを所持する出版社さまからまとめて翻訳や写植をした場合の見積もりを依頼されたり、自分の漫画を翻訳したいという個人の作家さまから依頼されたりと、規模の大小はありますが確実にお問合せの数は増えているなと感じます。

よくBPSの漫画翻訳の強みは何?と聞かれますが、これはズバリ「日本で数少ない“漫画翻訳専門”」だという点が強みではないかと思っています。
日頃からTechRachoを見て頂いてる皆さまはご存知だと思いますが、BPSはいわゆるIT系の開発会社です。漫画翻訳とは一見何のつながりもないように見えますが、その通り開発と漫画翻訳はほとんど関係がないのです。

実は、ある程度ファンの付いてきてくれているMANGA REBORNに集まってくれた翻訳家や写植家さんにビジネスでもお互にメリットを享受できないかと考えていました。
そこにMANGA REBORNの運営元=翻訳も当然できるだろう」と思ってお問合せをしていただいた企業さまがいてくださったおかげで、今のBPSの漫画翻訳事業があるのです。
まだまだ開発案件に比べたら社内売上構成の1割程度の事業ではございますが、今後更なる成長が期待できます。

クオリティに関しても、単なる翻訳会社ではなく「漫画翻訳専門クオリティ」を心掛け、多くのリピートを頂いております。クオリティの秘訣もこちらにまとめておりますので、是非ご覧ください。

もし、自社で抱えるコンテンツを大量に翻訳したい、自分の書いた作品を翻訳して欲しい、などあればお気軽にお問合せください。1ページから対応しております。

今回も読んで頂きありがとうございました。
と、思ったら新年初更新みたいですね。
最後になりましたが、新年あけましておめでとうございます。
今年は、更新ペースを上げられるように全社的に取り組んで参ります。

今年もBPSをよろしくお願いいたします!

 

第三者割当増資の実施に関するお知らせ

$
0
0

今回の増資について

日頃から弊社・TechRachoを応援してくださっている読者の皆様、こんにちは。TechRachoの運営会社であるビヨンド・パースペクティブ・ソリューションズ株式会社(本社:東京都新宿区、代表取締役:渡辺正毅http://www.bpsinc.jp/ 以下BPS)はこの度、現取締役3名への第3者割当増資により資本金4,996万円へ増資いたしました。今回の増資は経営体制を変更するためのものではなく、事業拡大のための成長資金として、収益力の強化を目指し、これまで支えてくださったお客様や仲間に少しでも弊社との関わりについて安心していただけるよう前向きに検討した結果です。今後とも宜しくお願い申し上げます。

※こちらは来年4月入社予定3名の新卒の内定式後の就業写真です。今年7月に1名、10月に1名、来年01月に1名、02月にもう1名を予定しております。
内定式の就業写真

弊社について

ビヨンド・パースペクティブ・ソリューションズ株式会社(BPS co,. Ltd.)は「電子書籍ビューアアプリ開発事業」「Ruby on Railsを使ったWeb開発事業」の2軸を中心に据えた、2007年設立のITベンチャー企業です。
「ICTを通じて日本好きを増やす」を合言葉に、ブラウザ閲覧用固定レイアウト向けEPUBビューアや日本語縦書きビューアエンジンの開発を行っています。近年では Web技術の世界的標準化推進団体であるW3C(World Wide Web Consortium)への加盟も果たし、Web上の日本語表現普及にも注力しています。

【ゆるふわDocker部】気軽にDockerを使うのもいいじゃない

$
0
0

morimorihogeです。1年以上ご無沙汰している間に艦これは卒業してゴ魔乙に引っ越しました。

最近弊社Webチーム内で標準ツール化してきたDockerについて、そこそこ知見も溜まってきたので現状の感想をまとめてみたいと思います。
また、Dockerを開発チーム内で利用するにあたり、もっと気軽な使い方をしてもいいんじゃないかなと思っているところがあるので、ゆるふわDocker部の提案をしたいと思います。

雑なDocker現状まとめ

まずは僕の私見としての現状のDocker事情をまとめてみます。

Docker

Dockerってイケてるの?

Docker自体についてはあちこちでいろんな記事も出ているので今更解説することは避けますが、開発者関連の話題状況や実際の周辺サービス事情を見ている限り、そろそろ「一過性の流行りモノとしてのなにか」から「実用シーンを見定めて実用化も考えて良いもの」になってきている印象を受けます。
初期は色々と不便なこともあったDocker CLIもdocker execの実装などを経て今もなお使いやすく進化しているのが見て取れます(ちょくちょくAPIバージョン互換が切れるのはめんどいですが)。

ContainerやDocker Image管理についても、公式GUIのKitematicを始め、ブラウザで管理できるツールなどもあり、多少初心者向けの門戸が広がってきたように思えます。
何より、Docker周りのコミュニティが活発なので、新しい情報に比較的アクセスしやすい状況ということで、今はDockerを新規で勉強するにはちょうど良い環境にあるのではないでしょうか。

本番で使えるの?

実際にサービスを運用する本番環境でDockerが使えるのか?という話を考えてみます。
いわゆる本番環境に新しいモノを導入する点では、いくつかの判断基準が出てくるかと思います。すなわち、

  • 安定性:サービスが停止せず動き続けられるか
  • 保守性:構成変更やメンテナンスが容易に可能であるか。脆弱性等が発見されたときにセキュリティパッチや対策方法が遅滞なく提供されるか、コミュニティが活発で問題に対する回答が見つけやすいか
  • 交換可能性:もし当該技術を使い続けられない要因が出てきたときに、他の同等環境へ乗り換えることが可能か(過剰にロックインされないか)

あたりが気になる所かと思います。Dockerはそうした点ではまだ一部の技術に自信のある組織が運用するに留まっている様に見えます(私見)。
普段から最新の情報を常に追いかけられるスタッフがいる組織なら大丈夫でしょうが、あくまでサービスを構成する1要素、1ツールとして利用するにはまだ「何かあったときに自分でケツを拭くこと」のハードルはまだ高いのかな、と思います。

どこで使うのがいいの?

そんなわけで、現状弊社内でのDocker利用は主にテスト・開発環境に留まります。一部本番系で利用しているサービスもありますが、それはDockerがうまく利用ケースにマッチした場合のみで、インフラを含めた全Docker化の様なagressiveな利用はしていません。
テスト・開発環境での運用については最悪ぶっ壊れても影響範囲が小さいことと、テスト・開発環境に使うCPU/メモリリソースの節約の観点から効率的であるということから採用しています。また、テスト・開発環境でしばらく運用してみることで、今後本番環境での利用も視野に入れた評価をできるということも狙っています。

Dockerをもっと気軽に使いたい

本番ではまだちょっと恐いかもしれないけど、触ってみないと使えるかどうかも分からないじゃないか!というわけで、もっと気軽にDockerを使いたい、、、ですよね。

14098888813_bec60d595d_o_FotoSketcher

Dockerって難しい?

Dockerについて調べると、単機能のcontainerを使った運用の例がモデルケースとして挙げられることが多いです。
そういった流れの中では、MySQLやMemcached等のサービスごとにcontainerを分けることで、一つ一つの管理単位を小さくまとめたり交換が容易になるといった昨今のマイクロサービス的な考え方にも通じる話が思想として出てきます。
こうした考え方はDockerの設計思想であり基本なので、理解しておくことに超したことはありません。実際用語定義レベルは流石に理解していないと運用そのものに支障を来すので理解すべきです。

・・・しかし、本当に今運用しているサービスをそんな簡単にcontainerに分離できるものなのでしょうか?

Dockerガチ勢の意識の高さと実運用の狭間で

本来のDockerの思想に則ったDocker運用を行う人達を社内(の一部)では「Dockerガチ勢」と呼んでいます。Dockerガチ勢の作るシステムは、各Docker ImageはDockerfileが提供され、手元でビルドからでき、一つ一つのcontainerはなるべく単機能に閉じており、複数のdaemonを組み合わせて動くようなサービスは複数containerで構成されていたりします。

これらのシステムはもちろんDockerで構築されるインフラとしてはあるべき姿なのですが、正直なところそこまで小さなcontainerに分離するのは面倒なのです。

複数containerを連携させるのが面倒臭い

Docker Containerは単体ではVMに近い使い方ができますが、container同士で通信をさせようとすると途端に面倒になってきます。container Aとcontainer Bの間で通信させたいと思ったとき、A <-> Bで相互にIPなりネットワークなりを繋ぐ設定を書かないといけなくなったり、このネットワーク周りは現在進行形で結構Dockerの仕様が大きく変わっていっている部分でもあります(クラスタ対応とか考えるとこの辺は元々難しい部分なので仕方ないですが)。
単純に1プロセス分だけ接続すれば良ければまだ管理できそうではありますが、監視系も動く様にしたりなど考えていくと割と早い段階で考えるのがおっくうになってきます。

沢山のcontainerを管理するのが面倒臭い

containerが増えればそれだけ管理するのも面倒になってきます。表から見ると1つのサービスなのに、裏では複数のcontainerが動いているとなると監視対象も増えますし、基本ライブラリ関連のアップデートがあればそれぞれのcontainerで対応する必要があります。うーん、考えるのがしんどい。

Dockerfileをきれいに保つのが面倒臭い

DockerfileはChefやAnsibleのrecipeの様なもので、なるべくきれいに保たれているのが良い状態であるのは確かだと思いますが、これをきれいに保つのは思いの外面倒だったりします。
Dockerfileを更新するまでは良いのですが、動作検証をするにはdocker buildせねばならず、動いているcontainerを修正するのなら簡単なのに・・・といったことは割とよくあります。

ゆるふわDocker部のススメ

そんなわけで、弊社社内ではまずは意識の高さには多少目を瞑りつつ、なるべく実運用に載せやすい方法を模索してきました。その結果、Dockerガチ勢に対してゆるふわDocker部を自称して少しずつDockerに慣れようとしています。
以下、ゆるふわDocker部のDocker運用の一端を紹介します。

14098888813_bec60d595d_o_FotoSketcher2

containerはモノシリックに。1 container 1サービスに詰め込む

MySQLもRailsも、1つのサービスの構成要素は全て1つのcontainerに詰め込みます。イメージとしては1 VMで構成されたシステムをまるごと1 containerに入れる形となります。
これにより、開発者間でcontainerを受け渡す時もdocker export|importするだけで済みますし、開発環境用Dockerサーバでdocker psしたときに大量のcontainerに面食らうこともありません。

Dockerfileの管理は諦める。受け渡しはDocker Imageで

きれいなDockerfileを書くことは諦めます。受け渡し・移動の際はdocker exportしたイメージを使い、container内の設定が必要になったときは潔くshellを叩いて直接修正します。
これにより、containerの設定変更は実質テストサーバで動いているものを直接修正するのと同じ手間でできるので、ほとんどDockerを意識せずに利用することができます。

今動いているサーバを丸ごとDocker Imageにして動かしちゃう

そもそもcontainerを構築する際、新規でcontainerを作るのならともかく、既存サーバをcontainerにしたいということが良くありますが、そういう時は雑に丸ごとtarで固めてDocker Imageにしてしまいます。環境によって多少の微調整は必要ですが、kernelやネットワーク周りでの環境依存があまりないサーバであれば、大体そこそこ動きます。
本番環境として運用するにはきちんと検証してから使いたいですが、テスト・開発環境で一時的に動かしたいといったレベルであればこれで充分なことも多いです。

まとめ

そんなわけで、社内でのゆるふわなDocker運用について、軽く概要を書いてみました。それぞれの具体的なコマンドや注意点などは今後個別に書いていこうかと思いますが、本記事では意外とこんなに雑な運用でもDockerを便利に使うことができるということを紹介しました。

意識が高いのも良いのですが、意識の高さ≒ハードルの高さにも繋がるので、それが導入の障壁になるくらいなら多少は意識を下げて布教に努めるのもいいんじゃないの、というゆるふわDocker部でした。

夢溢れる製品開発事業にさらに投資して拡大を目指すまで。2015年度振り返り。

$
0
0

あんこう鍋

こんにちは。BPS株式会社代表の渡辺です。意外にも私の投稿も見てくれてる人もいるみたいで、先日も、連絡してくれた方と食事してみました。日本語の練習を兼ねて続けていたことが出会いに繋がっていて嬉しいですね。大好きなあんこう鍋がでてきて感無量です。

自己紹介:渡辺正毅、31歳

アメリカ育ち、大学から日本へ。卒業後NHN(ハンゲームとかLINEとかCOMICOとか作ってるところ)に初めての新卒エンジニアとして就職し、1年くらいで退職。その後BPS㈱を設立し、以来、会社の弱い部分を補強しようと日々頑張っています。会社が成長していれば、毎年業務が少し変化していきます。

去年は優秀なデザインPM、開発PM、開発人員と巡りあいがあり、今まで以上に同僚の方々に助けていただいた1年でした。おかげさまで今年も少し仕事内容がかわり、会社の拡大路線に向けての準備が新たなミッションとなりました。

自社紹介:BPS株式会社

電子書籍関連商材開発&販売、Ruby on Railsによる受託開発(請負・委任)

集合写真

30人弱の今年9期目の開発会社です。電子書籍関連商材開発と導入、そしてRuby on Railsによる受託開発が主要業務内容となります。これらとあわせて、漫画翻訳やWebデザインやWebマーケティングの支援業務も行っております。

赤字になったことがないこと、優秀な個が多いことが特徴

2015年度売上と支出
※緑が収益、黄色が支出です。具体的な数字は伏せています。3月末頃に最新のデータに差し替えます。

今年度も例年通り増収増益で無事終えられそうです。また今年は、初めて全事業黒字となります。結果が示すとおりリスクを避けた投資を続けてきており、小さな企業であるにも関わらず複数の事業を展開できています。詳細は別記事にまとめていますが、個が動きやすい文化を作り続けてきたことが大きな要因と思います。

2015年度の目標と課題

電子書籍業界で”シェアをとる”

弊社の電子書籍事業は電子書籍を閲覧するためのビューアを開発して提供することです。事業を始めた2010年から電子書籍市場はいまや約2倍の1200億となり、その中でビューアビジネスは商流全体の3%ということで、約40億円市場が我々の選んだ戦場です。この市場を選択した理由はさておき、弊社には30人近く社員がおりますので、少なく見積もっても2億円分は社会のお役に立てていないと会社存続すら危うい計算になります。乱暴に計算すると、狙っている市場の約5%のシェアになります。大手企業ひしめくなかで、5%とはいえ弊社のような小さな企業が”シェアをとる”という挑戦は全員が力が合わせる必要があると感じ、あえて短期的目標を言語化した初めての試みでした。

開発の方針転換

事業として電子書籍の販売を開始するためには、それなりの初期投資が必要になります。そのため、お客様にあたる企業は必然的に名のしれたところが多く、社員規模も弊社の100倍が平均です。先方の担当部署のほうが弊社全体よりも大きいこともしばしば。それに対し、弊社は少数精鋭の体制をブラッシュアップしてきたため期待以上の成果を出し続けるためには、取引先企業とは一蓮托生となる意識で共同開発してきました。その結果が、取引先は多くて数社程度にとどまるものの、業界内で少なからず頼っていただけている一因かと思います。

一方で、”シェアをとる”方針とはかけ離れた動きをしており、長期的にみればこれが商材開発への先行投資と広範囲からの知見の収集が疎かになる要因になります。そのため、分散している事業のうち、過去8年にわたり弊社の収益基盤として継続的に成長し毎月5万人以上が開発Tipsを見に来てくれるWebアプリケーション開発の情報発信サイトの集客源となるコンテンツをつくったRailsアプリ開発チームを合流させより柔軟なチーム編成が可能にします。そして、他社との提携を強化して総合力を高めていきたいと考えています。これらの改善が今後の成長に直結すると信じて動いた結果が、本年度の増収増益および全事業黒字化なのかもしれません。先日発表した第三者割当増資による会社体力強化も含めて、去年かかげた目標に向けてまた一歩前に進めたと思います。

2016年のテーマは”拡大”

マネジメント層の強化、評価の仕組み作り

引き続き”シェアをとる”という目標に対し、やるべきは、
取引先を増やす

パラレルで進める仕事を増やす

仕事を指揮する人を増やす

作る人が指揮する人を兼務するか、採用するか、(引き続き提携先を増やすか、)と判断しています。

これまでは作る人が多く作る人の動きを最大化するための仕組みづくりが先行してきた分、これからは拡大路線で必要になっているマネジメント層の受け入れ体制と人財多様化に向けた評価の準備が必要ですね。自身がスキルアップする以外にも、相互教育や部下の育成などは比較的これまで考慮が少ない分野でした。今のところ今の人員で今の仕組みがワークしている分、この試行錯誤は注意しないと痛みを伴いそうですね。

既存メンバの成長や変化に伴う会社制度の変化

今年度はスタッフとスタッフの生活の変化が多かったように感じています。たとえば、子供が生まれて佳境時に残業できない代わりに常に社内チャットツールで連絡を取り合えるように意識するようになったスタッフがいたり、去年までサポートがメイン業務だったのに、いつのまにかプロジェクトリーダーになって部下が増えたりしているスタッフ、更には開発を一部外注することが増えたことに伴い外注管理やプロジェクトマネジメント業務が増えたスタッフなど。社外での役割、社内での役割の変化によって、殆どのメンバが希望する職場環境や効率の良い仕事方法が多少変化していきていることが伺えます。この変化にたいし、どこまで会社として皆に望ましい環境づくりができるかが大きな課題であり、前項のマネジメント層の強化に繋がっていくと考えています。また、今後の採用にも好影響がありそうなので真剣に取り組みたいところです。

業務範囲の拡大、業界への貢献

取引先企業様からの期待も大きくなってきています。内容は様々ですがB2Bでお仕事させていただいている以上、より良いものをより安価で大量に提供してほしい、という要望に行き着きますよね。しかしながら、利益を削るのは様々な限界が生じてきますので、それよりも弊社独自の価値を増やすことと、業界自体の発展に寄与できるように努めたいと感じています。具体的な内容については、選択肢の絞り込みと予算分配を決めきれていないので、また改めて報告させていただきます。

開発会社が開発を外注するときに注意していること◯選(請負・準委任問わず)

$
0
0

BPSの会社概要ページからのもらった画像

こんにちは。BPS㈱の渡辺です。新宿で30人程度の開発会社を運営してます。Railsの開発会社として多少知られているかと思います。少し前から電子書籍関係の商材を扱っている企業としても知られているかと思います。今まで社内で概ね開発を完結させてきたけど、需要にたいして社内供給が間に合わないとき、パートナーを探すしかないですよね。外注を検討していると、弊社の開発者から”これ自分達で作りたかったな…”、と言われるので、後で迷惑かけちゃったときの沸点の低さを鑑みてしっかりと外注先選定をしなければ、と常々思っております。ちなみに僕は、むかーしは開発していましたが、今は立場上マネジメントに近いことをしています。自分への戒めの念も込めて、経験をもとに注意点を列挙してみました。何かの参考になれば幸いです。

発注前に気をつけたほうがいいこと

BPS社内の写真

発注前に9割くらいのリスクは軽減できますもんね。何事も計画が大事。とはいえ、発注後にどうリカバリするかも非常に大きな破壊力をもつ決断を強いられるので、これはこれでまた今度まとめてみようかなと思います。同僚に、執筆は勢いが大事、というアドバイスをもらいました。打ち合わせまでの時間ないで書ききれるところまでを目標にします。ということで今回は発注前。発注後に関してはまた今度。さて、本題です。

技術わかりそうだけど受託開発経験や共同開発が殆どない

さすがに技術もダメで受託開発経験ないところは皆さまお断りしますよね。つい数年前まではこういった業者がわんさかいましたよね。SIer×ブラックといったテーマで文章書いている人が増えたのもこの時期でしょうか。最近では発注側の担当も注意深くなったのか、僕らもベンダーとしてお客様のところにお伺いすると、とても技術に詳しい方や技術部門を統括している方が対応してくださることが増えました。弊社にも開発会社さんがいらっしゃる時も、技術に詳しい方が提案営業にきてくれるようになってきました。技術詳しいし、話せる。そんな人が増えた印象です。とりあえず今目の前にいる人が開発を見てくれるなら大丈夫かもしれない、といった信用ラインは突破してくれる。まだまだ貧乏暇無しな状態で毎日右往左往しているので、おかげで完全に時間の無駄になることが減ったですね。

ですが、会った方が直接案件を担当してくれないこともありますし、担当してくれたとしてもその方やその方が属する会社に仕事としての開発経験が少ないこともあります。前者の問題点はわかりやすいし問題にならないこともありますし、今回は割愛します。後者の問題は、技術的ハードルは超えていても、仕事として開発を全うできない可能性にあります。僕には、短距離走に自信がある陸上選手がトライアスロンに挑戦するように見えます。走る(技術)だけだと時間ないに完走できないんです。そもそも長距離だから完走できないかもしれない。それに、自転車も水泳もある。プロマネ業とか、プロジェクト後のソースコード保守制とか、いろいろ。結果、想定(見積)通りに全然進まずプロジェクト事態が消滅するか、良くて大幅な延納に繋がります。経験も悪気もない企業さんは、それでも付き合うか考えれば良いですよね。逆に、完走できないリスクを発注側に過度に押し付けるような会社さんは注意が必要と思います。個人的に注視しているのは以下です。

何でも別途見積

もちろん想定外のことがおきて正当な別途見積が発生するのはしょうがないと思います。同じ開発会社ですからわかります。でも、経験があればある程度事前にリスクは想定できますし、織り込み済みで見積が可能で、そのリスクの情報共有によって双方で対処できることがあります。なので、開発者同士で不自然なほど序盤で別途見積をプッシュしてくるようだと要注意と思っています。あるいは、自社のRFPや事前の要件定義がダメすぎるか、ですね。

アジャイルだからドキュメント書かないぜ的な開発スタンス

最近流行ってますよね、CTOや開発チーム貸し。正しく開発すれば正しくアウトプットはでます。アジャイルが適していて、かつ経済的なば場面もいっぱいあります。だからそれがダメとは全く思ってません。ただ、この流行りを使ってお客さんをロックインしたりスケジュールをないがしろにする動きが最近多いですね。弊社に既存システムの改修を依頼してくるお客様のなかの一定割合は、信頼してシステムを創ってもらっていたけれど、全然進んでいるようにみえないし、見せてもらったものは欲しかったものと異なるし、もう期日が差し迫っているのでどうにかしてほしくて困っている、というケースです。最低でも期日までに必要な機能が動いていることを保証してほしいケースが殆どなため、それに合わせた契約形態を真剣に考えるべきですよね。

別業務の合間程度に受託開発している

個人的にこれが一番癇に障ります。自社サービスなどを持っていてそれを会社として最優先されることは、とても良いことだと思いますし、応援したいです。最近は自社サービス開発と受託開発の両方に力をいれてる開発会社さんとても多いですし、うちもそうですし、共感するところが多いです。さすがに自分の子よりも他人の子を愛してくれとは言えないし、契約前に何を書かせてもその事実はかわらないし、あとからお金で精算しても気分が悪い事にはかわりないし、どこまで頑張ってくれるかは事前に目処をつけておくべきですよね。なので発注前に気にしているのは主に下記の2点。

やりきってくれそうか

1つ目は、その会社や担当の風土から仕事をやりきってくれそうか、です。目の前にいるやつが性善説で生きてるやつかどうか、など。問題を起こしたときに正す気概があるか。自信だけじゃなくて覚悟もありそうか。僕も性善説で生きている人間なので見極められていないんですけどね☆

開発体制と計画

2つ目はもうちょっと現実的です。別業務に専念している会社さんほど、規模の割に大人数は開発体制を提案してくることがあります。それも、あまり余裕のないスケジュールで。欲しいのは、他人の子供でもこうこうこういうふうにしっかり守って育てていきますよ、という計画書ですよね。その計画書に抱えてもいない大量の担当者とパツパツのスケジュールを組み合わせた線表がひかれていると、とっても不安になりますよね。この辺の整合性の確認が必要です。

請負か準委任か

請負でも準委任でも、ウォーターフォールでもアジャイルでも、正しく適切に遂行すればどちらも成果はでます。プロジェクトがどちらに適しているか、というだけの話しですよね。請負は請ける側からするとリスクが高く収益も高い。準委任は逆ですね。でもこれは正しく業務を遂行した場合の話です。エースを投入してしっかりプロジェクトマネジメントをしていないチームなら、準委任のほうが請ける側からするとリスクは低く収益性が高い。小規模な案件ならエース投入で速攻終わる可能性がありますね。開発量が多い案件なら安定した計画があったほうがいいですね。案件の性質と、外注先開発会社と担当者の特性の相性を見てから判断すべきですよね。

自社担当者との相性

以外と忘れがちなのかなと思うのでこれです。最後に気合でやりきってくれるほうが嬉しいのか、計画を立ててちびちび前に進めてくれたほうが嬉しいのか。僕は人付き合いが苦手なのでなるべく少ないコミュニケーション量でまるなげしておいたら適当に適切にいい感じに知らない間に完了していることが嬉しいのですが(笑)、仕事方法に想い入れや拘りをもって取り組んでくれる人を発注担当にするでしょうから、組合せは大事ですよね。

ソースコード品質という成果物

予め要求していた機能があり、要望に答えられるシステムが期日までに完成する。それも、中小の小回りと(低)価格で。弊社でも受託開発を行っているので、これだけでも笑っちゃうくらい大変なのは重々理解しています。ただ、追加開発や改修が必要になったときにつくり直しレベルのものを受け取っているとけっこう辛くなっちゃうのでソースコード品質含めた過去実績の確認や、ソースコード品質に関する基準などは事前にすり合わせてほうが幸せです。品質は、ちゃんと話せば、コストやスケジュールみたいなふわっとしたものと違い、できるかできないかの話し合いがしやすいです。

技術力が高く価値観のあう開発会社さんを探しています

BPS社内の写真

弊社業務をご覧いただきもし協業の余地ございましたらぜひご連絡ください。弊社のやっていることと今後の目標についてはこちらまたは↓のバナーをみて詳細ご覧いただけたらと思います。今後ともよろしくお願い申し上げます。


【ゆるふわDocker部】任意バージョンのPostgreSQLコマンドを実行して外部DBに接続する

$
0
0

morimorihogeです。そろそろラナンの探索マップがコンプリートできそうです。

前回の記事でゆるふわDocker部の提案をしましたので、ゆるゆるとDocker Tips的なものを垂れ流していこうと思います。今回はバージョン依存の強めなPostgreSQLのCLIコマンドをDocker経由で簡単に実行する方法を紹介します(今回は9.3系ですが、適宜他のバージョンで読み替えても使えるはず)。Dockerを使うことでローカルシステムにインストールされていないPostgreSQLクライアントで外部のPostgreSQLサーバに接続することが簡単になります。

確認環境はMac OS X El Capitan、Docker 1.9.1で、Docker Toolboxビルトインのboot2dockerを使っています。いつものことですがご利用は自己責任でお願いします。

PostgreSQLのクライアントバージョン問題とは

MySQLと並んで人気OSS系RDBMSのPostgreSQLですが、よく引っかかる問題としてバージョン依存性が強いというものがあります。
例えば、クライアント側のバージョンが9.2.9でサーバ側のバージョンが9.3.1のケースでpg_dumpコマンドを実行すると、以下の様なエラーが発生して接続に失敗しまいます。

$ pg_dump -h somehost -U someuser -W somedb
Password:
pg_dump: server version: 9.3.1; pg_dump version: 9.2.9
pg_dump: aborting because of server version mismatch

DBサーバとアプリサーバを分けている時なんかには割と発生しがちな問題ですね。他にもたまに古めのサーバに接続しないといけないときはちょこちょこあるので、困ることがあります。

Dockerをでかいバイナリコマンドとして使う

今回実行したかったのはpg_dumpコマンドだけで、dumpデータさえ取れれば後は手元にインポートして使うぜ、という状態でした。そこで、使いたいバージョンのPostgreSQL containerを取得してそのバージョンのPostgreSQLコマンドを使うという用途でDockerを使うことにしました。
今回はDocker HubでPostgreSQL関連のDocker Imageを漁って使ってみましたので、手順を追っていきます。他のプログラムでも同様の手順で大体はなんとかなると思います。

Docker Hubから使えそうなイメージを探してくる

まずは、Docker Hubの画面一番上の検索から「postgres」で検索すると、

Screenshot 2016-02-15 18.13.21

オフィシャルのpostgres imageが見つかります。

Screenshot 2016-02-15 18.14.42

Tag一覧のページを見ると、9.3系では9.3.10が生きてることが確認できます。

Screenshot 2016-02-15 18.17.15

というわけで、欲しいDocker Imageは「postgres:9.3.10」であることが特定できました。
しかし、ここで良く見ると、9.3系のTagで古いビルドバージョンのもの(9.3.9以下)は削除されていっていることが分かります。これだと9.3.11が出た後に最新をpullすると9.3.10が使えなくなってしまいますね。

そこで、よくよくREADMEを読んでみると、9.3.10の他に9.3というTagがあることが分かります。

Screenshot 2016-02-15 18.49.09

というわけで、9.3系であれば良いということであれば、Tagには9.3.10ではなく9.3を指定するのが良さそうです。最終的に使うDocker Imageは「postgres:9.3」が良さそうです。

イメージをpullして、使いたいコマンドの実体を探す

イメージ名が特定できたので、取得します。以下のコマンドで調べたDocker Imageを取得できます。タグ名(ここでは9.3を省略するとlatestが取得されます)。

$ docker pull postgres:9.3

ダウンロードが完了したら、実行したいコマンドのパスを調べていきます。とりあえずシェル(/bin/bash)を立ち上げて欲しいコマンド(pg_dump)を探索してみます。
ここでの「-it」オプションはインタラクティブ&仮想TTYオプションで、対話式のコマンドを実行するときにはこれを付けるモノだと思っていればOKです。「–rm」を付けるとコマンド実行終了時に自動的にcontainerを削除してくれます(docker ps -aしたときに「うわあああああ」ってならなくて済みます)

$ docker run -it --rm postgres:9.3 /bin/bash
root@4d0c308aa3c6:/# which pg_dump
/usr/lib/postgresql/9.3/bin/pg_dump

ありました。これで、欲しいコマンドは「postgres:9.3の/usr/lib/postgresql/9.3/bin/pg_dump」であることが確認できました。
一応ためしに実行してみましょう。

$ docker run --rm postgres:9.3 /usr/lib/postgresql/9.3/bin/pg_dump --help
pg_dump dumps a database as a text file or to other formats.

Usage:
  pg_dump [OPTION]... [DBNAME]

General options:
  -f, --file=FILENAME          output file or directory name
  -F, --format=c|d|t|p         output file format (custom, directory, tar,
                               plain text (default))
  -j, --jobs=NUM               use this many parallel jobs to dump
  -v, --verbose                verbose mode
(以下略)

大丈夫そうですね。これでとりあえず欲しかったコマンドは使えるようになりました。

DockerコンテナからリモートのPostgreSQLサーバに接続する

ここまででpostgresコンテナから任意バージョンのコマンドを実行することはできましたが、このままだとまだ接続したいサーバに接続できていません。ここからはMac環境依存です(Linuxでも大丈夫ですが、Windowsはsshコマンド周りがダメかも)。

MacでDockerを動かす場合、VirtualBox上でboot2docker等のDocker HostとなるLinuxを動作させ、そこに接続して使うという形が一般的ですが、これだと動かしているcontainerは論理的にはVirtualBoxのprivate network上に存在する状態になっています。
今回、dumpを取得したいDBサーバがAWS VPCの中にあったため、接続するためにSSHトンネルを張る必要が出てきました。

SSHトンネルについては過去の記事の後半で解説しているので、よく分からない人はそちらも参照して下さい。

言葉で説明するとわかりにくいので、ネットワーク構成をまとめてみました(文字が一部小さいので適宜拡大して見て下さい)。

Screenshot 2016-02-15 23.37.38

ローカルのMacで上で動作するVirtualBoxでboot2dockerのDocker Hostが動き、その上でpostgres:9.3のcontainerを動かします。
AWS側は良くある構成ですが、APPサーバはパブリックIPを持っているため外からSSHアクセスできますが、DBサーバはVPCのプライベートネットワーク上にあるため直接インターネットからアクセスはできません。

ここで、今回接続したい経路は下図赤線の通りです。
図で書くとpostgres:9.3のDocker Containerがかなり深い位置にあることが分かるのではないでしょうか。

Screenshot 2016-02-15 23.40.25

さて、postgres:9.3 containerからAWS VPC上のDBサーバに接続するにあたって、今回は以下の方針を取ることにします。

  1. MacのVirtualBox向けネットワークインターフェースからAWS VPC上のDBサーバのpostgresqlポート(5432)へのSSHトンネルを掘る
  2. postgres:9.3 containerからMac上のvboxnet1に対してpg_dumpを実行する
  3. 前記のdockerコマンドはLocal Mac上で実行するので、pg_dumpの結果を標準出力から取得してLocal Mac上に保存する

接続イメージは下図の通りです。青線がSSHトンネル緑線がpg_dumpコマンドの範囲になります。

Screenshot 2016-02-16 00.18.31

この方式の利点は以下の通りです。

    • SSHトンネルはさらに多段にすることも可能なので、やろうと思えばもっと複雑なネットワーク上の深い所にあるサーバにもLocal Macから透過的に接続できる(汎用性)
    • SSHトンネルのlisten addressはVirtulBoxのプライベートIPのため、もし社内intra networkに悪い人がいてもこのSSHトンネルを利用することはできない(安全性)
    • 必要なSSH接続導線は「Local Mac -> VPC上のAPPサーバ」「APPサーバ -> DBサーバ」の2つなので、APPサーバやDBサーバに新規でSSH公開鍵を登録する必要がない(保守性)

上図では省略しましたが、本来Docker Hostはeth0にVirtualBoxのNATネットワークインターフェースを持っていて、これを通すことでpostgres:9.3 containerから外に直接SSHトンネルを掘ることもできますが、その場合はpostgres:9.3 containerでSSH鍵ペアを作成し、今回のコマンドを実行するためだけの公開鍵をAPPサーバに配置する必要が出てきたりして今ひとつイケてないです。これだともしその後そのcontainerを誰かと共有したりするとAPPサーバへの接続権限ごと渡ってしまうことになってしまいますしね。

SSHトンネルを掘る

以下のコマンドでOKです。これで前述の図で書いた青線のトンネルが掘られます。

$ ssh -fNL 192.168.99.1:15432:a.b.c.d:5432 w.x.y.z

注意点として、Macに入っているSSHの-L(ローカルフォワード)オプションでは、listen addressがデフォルトでは127.0.0.1(lo0)になってしまう点です。ループバックインターフェースでlistenされるとDocker Hostからは接続できないため、明示的にvboxnet1のIPアドレスである192.168.99.1を指定しましょう。
※0.0.0.0にしても接続はできますが、その場合en0からもこのトンネルにアクセスできてしまうため危険です

Dockerコマンドを実行する

ようやくDockerコマンドを実行します。これまででpostgres:9.3上のpg_dumpコマンドを実行するところまではできていましたので、あとは通常通り-hオプションや-pオプションで接続する設定をしてやれば良いです。
ただ、ここで一点問題が出て、そのままだとパスワードをプロンプトから入力させる-Wオプションがうまく動きませんでした。そこで、コマンドラインからパスワードを設定してやる必要があります。
PostgreSQLではPGPASSWORD環境変数が設定されていれば、それをパスワードとして実行してくれるため、環境変数を渡します。これにはいくつか方法があり、bash経由で1コマンドとして実行する方法なら

docker run --rm postgres:9.3 /bin/bash -c "export PGPASSWORD='pg_password' && /usr/lib/postgresql/9.3/bin/pg_dump -h 192.168.99.1 -p 15432 -U pg_user db_name"

となりますし、-eオプションを使って設定するなら

docker run --rm -e PGPASSWORD='pg_password' postgres:9.3 /usr/lib/postgresql/9.3/bin/pg_dump -h 192.168.99.1 -p 15432 -U pg_user db_name

となります。どちらでも問題なく動作しますが、前者は最初自分で思考錯誤してたときの方法で、後者は社内Slackの#docker channelで垂れ流してたらyamasitaが教えてくれました。後者の方がシンプルですね。

とにかく実行するコマンドはこれ

長々と解説してきましたが、Docker環境が構築されてあれば、実行するコマンドは以下の通りです(IPアドレスやポート番号は図に準拠してるので、各自環境は自分の環境に合わせて下さい)。

docker pull postgres:9.3
ssh -fNL 192.168.99.1:15432:a.b.c.d:5432 w.x.y.z
docker run --rm -e PGPASSWORD='pg_password' postgres:9.3 /usr/lib/postgresql/9.3/bin/pg_dump -h 192.168.99.1 -p 15432 -U pg_user db_name > db.dump

終わり!閉廷!以上!皆解散!

まとめ

今回はゆるふわDocker部としてDockerコンテナを一つのでかいコマンドバイナリとして使う方法を紹介しました。ライブラリなどの環境依存が強いコマンドはDockerとの親和性が高いので実用的だと思います。
今後もゆるふわDocker部ではできるだけ簡単に実用的なDockerの使い方を不定期に垂れ流していこうと思いますのでよろしくお願いします。

追記:Dockerコマンドの短縮とgz圧縮

手順の中でpostgres:9.3のDocker Imageからpg_dumpのPATHを探す所がありましたが、実は普通にPATHが通っていました。なので「/usr/lib/postgresql/9.3/bin/pg_dump」と書いてあった部分は単に「pg_dump」で動きます。
また、dumpファイルを生のままdb.dumpファイルに吐き出していますが、受け渡しするなら圧縮してあった方が便利なので「| gzip -c」を付けて、

docker run --rm -e PGPASSWORD='pg_password' postgres:9.3 pg_dump -h 192.168.99.1 -p 15432 -U pg_user db_name | gzip -c > db.dump.gz

とすれば一気にgz圧縮されたdumpを取得することができます。まあこれは普通のシェル操作なので、Dockerに依存した話ではないですね。

最近のRails受託開発案件相談とエンジニアに求められるスキル傾向

$
0
0

morimorihogeです。某新聞沙汰になったゲームと違ってゴ魔乙は当初からガチャの確立明示はしてたり、☆5の使い魔がインフレで相対的に弱くなったりしないあたり、割とCAVEは良心的だなと思いました(小並感

最近Railsの記事を書いていないことに気づいたので、ここ最近のRails受託開発案件の傾向について書いてみようと思います。Railsエンジニアを目指す人や、今後Rails案件を増やそうと思っている開発会社さんなんか向けの内容です。

弊社&僕の位置づけ

観測範囲が僕の周りだけなので、まずは僕自身が普段どのような環境でRails案件と関わっているのかを軽くまとめておきます。

bps_logo

弊社の規模感など

今年で9期目の開発会社です。Webシステム開発の事業は当初から続いていますが、5年前くらい?(Rails 3.0.0のリリースくらい)にPHP開発メイン -> Rails開発メインになりました。
メンバはほとんどがエンジニア、または元エンジニアで、SESや常駐対応は基本的にお断りしています(もちろん案件によって打ち合わせや現地作業で事務所外で働くことはあります)。
社員数は大体20名前後で、お互いの顔と名前が一致させられる人数です。最近増資して規模拡大といった話もありますが、そのあたりは弊社代表渡辺の記事を見て頂くのが良いと思います。

事業としては電子書籍関連部門とWeb開発部門がありますが、前者は自社製品開発、後者は受託開発メインになります。僕がいるのは後者のWeb受託開発部門ですね。

僕の立ち位置

僕自身は創業メンバーではなく、学生時代にフリーランス外注として会社と付き合い始め、そのままいつの間にか中の人になってて古参になっていたという流れです。今ちらっと眺めていたら7年目くらいの様でした。もうそんなにいるのか(遠い目

現在の役割としては、Web開発部門のリーダーとして各種案件に関わっています。ただ、小さい会社&Rails開発自体が少人数で行うことが多いことから、プロジェクトによって窓口対応・ディレクション・開発・インフラ諸々なんでも必要そうな所の穴埋めをする形で入っているのが現状です。
最近は窓口や仕様調整などの上流寄りの仕事をすることが立場上多いですが、普通にRailsのコードを書くこともあります。

また、元々ジェネラリスト的なスキルセット持ち(物理・クラウドサーバ〜開発・窓口全部やってきた)なことから、新規のWeb開発案件については僕が直接ヒアリングしに行くケースが多いです。最終的に受注に至らなかった案件についても見積・調査まではするため、入ってくる案件相談の数自体はそれなりの数になるかなと思います。

営業チャネル

人脈経由でのご相談ももちろんありますが、最近のWeb開発案件では弊社Webサイトからのお問い合せがメインです。弊社開発体制については弊社HPのRailsページに諸々まとめています(2〜3年くらい更新してないので流石にそろそろ更新しないとですね)。

ここ最近の案件傾向の変化

では、最近の案件傾向に触れていきたいと思います。

interview-1018333_960_720

大きな企業からの相談が増加

数年前に比べると、確実に大きな会社からの相談が増えたように感じます。中小企業からの相談も引き続きありますが、これまではRailsを使っていなかったような企業からの問い合わせが来る様になりました。
これは弊社がおかげさまで有名になってきたというのもあるのかもしれませんが、RubyWorld Conferenceにここ数年出席していても感じることなので、市場傾向としても間違っていないと思います。

大きな企業の担当者様から直接ご相談を頂くこともありますが、間接的にいわゆる孫請け外注の相談を受けるケースでも中間に入っているSIerがRailsを指定(または使っても良いというOKが出ている)されているケースが見られるようになってきました。
この辺りからもRailsは「新しいモノ」から「実用に値する選択肢」として受け入れられ始めているなー、という感想です。

保守関連の相談が増加

Railsというと以前は新規開発や既存システムの作り直し案件という、実質ソースコードはスクラッチから開発する案件が多かったのですが、ここ最近は既に運用しているRailsシステムに関する相談が増えたように思います。

ご相談に至る経緯はお客様によって様々ですが、大体以下のようなケースに当てはまります。
※特定のお客様を対象にしたわけではなく、本当に↓のケースに当てはまるものが多いです

  • 昔作ったRailsシステムをずっと運用してきたが、セキュリティ上のリスクや追加開発の困難さの観点からRails/Rubyのバージョンをアップグレードしたい
  • 既に他社に依頼して開発・運用を続けてきたが、諸々の事情(コスト・担当者の入れ替わり・対応速度面など)で開発会社を乗り換えたい
  • 元々社内で趣味的に一部の従業員が業務改善に作ってきたシステムがいつの間にか社内業務のコアシステムとなったが、正式な開発チームが社内にいるわけではないので何かあったときのためにきちんとした保守体制を構築したい

流れとして感じるのは、Railsが流行り始めの頃に構築されたシステムがそろそろ風化してきており、きちんと保守してこなかったものにガタが来始めたという印象です。
一般的なWebシステムの耐用年数は大体3〜5年くらいだと考えると、手応えとしてしっくりくるのでそういうことなのでしょう。

業務に密接に結びついた仕様が複雑な案件の増加

Railsは元々scaffoldベースの高速開発の印象が強かったこともあってか、以前までは割と分かりやすいscaffoldに落とし込める案件(index/show/new-create/edit-update/destroyでほぼ足りる)が多かったのですが、最近はより複雑なUI設計や複雑な要件を求められることが増えたと感じます。

また、そういった複雑なケースを求められるのは業務システム系のものが多いため、実装上の仕様が複雑なだけでなく、お客様の業務フローや利用環境とのすり合わせが必要になってきます。インターネットに接続できないというネットワーク条件で動かす必要があってCDNが使えなかったり、動作しているサーバの手前のコンテンツフィルタの認証を通すためにHTTPヘッダ内のデータを参照・書き換えする必要があったりといわゆる「普通のスタンダードなRailsシステム」でない案件が増えた印象です。

ただ、こういった複雑だったりセキュリティ要件が厳しめのシステムというのはそれだけお客様のコアな情報にアクセスするシステムということでもあるので、いわゆるエンタープライズに近い領域にもRailsが使われる様になってきたという裏返しなのかもしれません。

エンジニアへ求められるスキル傾向

前記に上げた案件の変化に伴い、エンジニアに求められるスキルの変化について挙げてみます。Railsエンジニアなので、Rails tutorial等は当然クリアし簡単なWebサービスくらいなら一人で作れる、というエンジニアを前提としています。

260px-Ruby_on_Rails_logo.svg

古めのRails/Rubyを触れる知識とスキル

世の中はRails 5.0が出るぞーという状況ですが、数年前のRailsシステムを触ったり更新する案件では未だにRails 1系や2系、Rubyは1.8系といったレガシーなコードに触れる機会があります。
#findメソッドに「:conditions => 〜〜」とか書いてあるコードを「おおぅ・・・」と呻きつつ何をやってるか調べたり、最新のRailsスタイルに書き直したりすることができると、割と重宝されます。

弊社では、流石に古すぎる&テストもドキュメントもない状態の大きめRailsシステムをアップグレードするのは厳しいので作り直しをご提案するケースが多いですが、小さめのシステムだったり、コストがかかってもアップグレードしたいというご要望を頂く場合はRailsのアップグレードガイドを見ながらチマチマ更新していったり、左右に旧・アップグレード中システムを並べて動作確認、といった開発をすることもまれにあります。

流石に今更古いRailsを新たに勉強するのはモチベーションが上がらないと思いますが、需要は確実に存在する分野なので、他のRailsエンジニアとの差別化要因にはなるかもしれません。

RailsやHTTP/Webサーバ、文字コード等に関する深めの知識

社内インフラの様な特殊環境を要求されるシステムだと、普通のRailsのconfiguration程度では実現できない様なことを求められることがたまにあります。そういった際にはRails自体にモンキーパッチを当てたり、手前のnginxやapacheレベルで事前加工してみたりという対応する必要があります。
他にも、業務システムは未だに文字コードがCP932(WindowsのShiftJIS)だったりするケースが多いので、UTF-8に変換・CP932に再変換するときの変換できない文字問題に引っかかったり、外部システムの為に謎の固定長データを生成してやったりする必要があるなど、普通のRailsシステムでは触らないような問題に立ち向かう必要があります

業務系のシステムなどの経験が長いエンジニアなら大丈夫でしょうが、最近のWeb系開発からエンジニアになって、普段からスタンダードなRailsシステムしか触っていない様なエンジニアはこういった泥臭い部分にも目を向けてみると、スキルの幅が広がるのではないでしょうか。

SIer的なドキュメントの読み書き・ヒアリングスキル

案件やお客様に依存する部分がとても大きいのですが、いわゆるSIer的な「XX設計書」「XX計画書」「XX報告書」といったものを求められることが出てきました。
弊社では明らかに必要のなさそうなドキュメントについては極力作成をお断りするようにしていますが、別途見積の上で作成を引き受けることもあります。

正直実質1〜3人程度で開発していることが多いRailsシステム開発で、今後更新される見込みのないこういった書類を書くのは苦行だなあ、と思うことが多いのですが、そういったドキュメントの中にも必要だな、と思うものは確かにあります。
外部システムとの接続点のAPI仕様書やバッチ同期するファイルのデータ使用・同期スケジュール仕様、バッチの前後関係と障害時の影響範囲などはサボると後の保守をするエンジニアが苦しむことになるので、面倒でも最低限は作成した方が良いでしょう。

また、既存の他システムとの連携が発生するシステムでは、他社のエンジニアとの仕様調整なども必要になってきます。相手がRailsのような比較的新しい技術やWeb界隈のノリに近しい人なら良いですが、ガチガチの業務系なエンジニアを相手に話をしないといけない時には、お互いの文化の違いも認識しつつヒアリング・調整していく必要が出てきます

いわゆるSIer用語で言う「SE(えすいー)」的な動きができるエンジニアはあちこちを見ていても不足している印象なので、好きか嫌いかはともかく、やろうと思えばできる程度にはできる様になっておくと食いっぱぐれないのではないかと思います。

まとめ

以上、狭い観測範囲ではありますが、昨今の受託開発におけるRails案件の傾向と、エンジニアへの要求スキル傾向をまとめてみました。
ここに書いた様な内容に当てはまらない、いわゆるRailsらしい案件のご相談も頂きますので、以前まではあまりなかった領域の案件やスキルがRails界隈に出てきているよ、という程度に考えてもらえれば良いと思います。

そんな弊社で働くことに興味のあるエンジニアはこちらの採用ページからからお問い合せ下さい :)。

また、Rails関連の案件相談については弊社お問い合せページから問い合わせて頂ければまずはお話を伺わせて頂きます。

【速報】HTML5.1に向けた作業(翻訳)

$
0
0

W3Cブログに、HTML5.1について早速どんな作業があるか、どういう目標で取り組むかについてのブログ記事が出てきた(英文)ので、これを日本語で速報します。訳文は翻訳速度優先ですので、間違いなどありましたら指摘いただけると嬉しいです。

原文:https://www.w3.org/blog/2016/04/working-on-html5-1/

速報訳:

HTML5.1に向けた作業

HTML5は2014年にリリースされたけど、W3C HTML Working Groupなどの努力の結果だったよね。
その意図は、すぐ後に、後押しした出版活動のためだった。定期的なHTML標準の更新ね。
しかし、いくつか意味が違った。予定通りいかなかった。
今ではWeb Platform Working Group (WP WG)が向う方向はHTML 5.1のリリースだ。6ヶ月以内に。そして全体の仕事進行は、我々が意図するところにおいて、HTMLの安定板を出版できるようにすること。W3C勧告として年に1度が目標。

目標

目標の中心は、未来のHTML仕様を現実に沿うようにすること。その結果、仕様を明確に、可能な限りメンテして、もちろん全員の利害関係者に良い提案をできるようにする。そうできるように「HTMLの成功とは何なのか」を考える。

タイムライン

予定では、HTML 5.1勧告を2016年9月に出す。これの意味は、その前の勧告候補(CR)を6月中旬に、最新WCを軸としたCall For Consensus (CFC)に続いて出さないといけない。
簡単に人々がレビューできるようにするには、更新版のWorking Draft (WD)の出版がだいたい月に1回にしないといけない。利便性のために、変更は仕様自体に書こう。

長期的に好ましいのは「整頓の繰り返し」で、定期的な更新をHTMLに行い、その実装を相対的には真っ直ぐなものにすること。そうしているうちに、進行を追い掛けるのにGitHub Pulseを使ったり、@HTML_commitsをフォローしたり、@HTMLWGをツイッターでフォローしたりするだろう。

仕様に向き合う

仕様はGitHubにあるので、みんなPull Requestさえできれば、提案して変更できる。簡単な変更は、例えば文法修正など、とても学習の敷居が低い。ほかの簡単な変更も一般的に受け入れられるものだ。編集者は喧嘩しない。

もし何かを仕様に見つけて、それが一般的に世のブラウザで動かないようなものなら、ぜひとも
ここで起票
してほしい、もしよければ修正に加えてプルリクエストを送ってほしい。それを修正するような。我々はいつも除去する物があるか考えている。十分なサポートが少なくとも2つのブラウザで得られない仕様は、除去する対象になる。たとえ便利で、保持していてほしくても、期待して将来のサポートを待つと思っても、だ。詳しくは下の「incubation」を参照。

HTMLはとても大きな仕様だ。その開発は、複数のソースファイルの集合から成る。それはBikeshed Processorによって処理される。これは自動化によりリンクを多数のセクション間で処理するもので、要素定義などをつなげる。重要な変更は、それが編集上のものであっても、おおよそ必要とする基礎知識があり、Bikeshedの動きを知っていないといけない。我々は継続して向上させる。文書化して特に初心者が分かりやすいように。

実際の新しい機能について、我々が好むのは、別個のモジュールが開発されること。これを「incubated」という。これにより、実際のサポートが存在するようになる。いろんな実装者がブラウザをやったり、製作ツールをやったり、実用コンテンツを作ったり、ユーザーも参加したり、さらに標準化しようとしたときの準備として提案できる拡張的なHTMLの仕様になったりする。

Web Platform Incubator Community Group (WPICG)の設立目的は、上記のためだが、もちろん参加者が開発して提案するとき、どんな立場でもいい。もう一度言う。我々が参加者に要求するのは、提案への技術貢献を追跡して(WICGは補助する)、そうすることで我々が到達点に来たと知ることができる。人々が提案を持ってW3Cにコメントして、ロイヤルティーフリーの条項に貢献して、開発者が喜んで実装をして、他大な心配を抱えて特許訴訟について頭をかかえることがない、という到達点に。

テスト

W3Cの開発プロセスでは、勧告がWGへ要求するところによると、W3Cディレクターを説得しないといけない、としている。Tim Berners-Leeに対して仕様が

・十分に明瞭で、完全で、市場要求に適合して、独立的な相互操作性のある実装が各機能について行われ、仕様が実現されていること

これはHTML5.0でも行う必要があった。変更が提案されてHTMLを変えるとき、我々が求めるのは、十分なテストで説明づけることだ。その提案が相互操作性を改善していると。理想的にはこれらは自動テストに組み入れたシステムにして、Webapps test harnessのようにすることだ。しかし実際に我々の計画で受け入れているテストでは、必要な相互操作性を説明づけるものなら良しとしている:自動化できるものであっても、でなくても。

利益としてこれらのアプローチがもたらすもの、それはブラウザから機能が除去されるのを除いては(レアだが)、継続的な増大を相互操作性レベルに見出せること。変更を承認するたびに。これの意味は、いつでもEditor’s Draft (ED)のスナップショットが安定した基盤となって改善したHTMLバージョンになれるということ。それを我々が出版してHTML勧告の更新版にできる。

結論

我々が求めるHTML仕様−それは著者も実装者も、手軽に、自信を持って使用できるものであること。目標は完全の追求ではない(それは良への敵だ)。むしろHTML 5.1を5.0より良くすることだ。5.2までのね。

そして我々が各自に求めることは、気軽に参加してHTMLを向上させる活動をしてほしい。各自の目的もあるだろうし、Web全体のためにもなる。

【速報】Firefox 48 で text-combine-upright: all; が有効に!

$
0
0

Mozilla の開発者の Xidorn さんから連絡が来て、Firefox 48 から text-combine-upright: all; が対応される模様です!

BPS では、Writing Modes Level3 の勧告化を推進する活動をしているのですが、その一環で text-combine-upright が unprefix な状態で二つ以上のブラウザで実装されるのを待っていました。Google Chrome と合わせてこれで二つのブラウザで実装されることになるので、勧告化に向けてまた一歩進みました:)

また、Microsoft も Edge において unprefix を実施することは明言しているので、着々です!

初九州!出張も何人かで行くと楽しいですね。

$
0
0

また3ヶ月ほどご無沙汰しておりました。BPS㈱の渡辺です。目の前の仕事でバタバタしているとどうしても更新が滞ってしまいますね。決算時期や個人的に引っ越しと子供の小学校入学などが重なりあたふたしておりました。おかげさまでだいぶ落ち着きました。

システム開発会社のパートナー探し

年度末はどうしても仕事が溢れるので、ちょっと手前で、お世話になった九州のお客様に挨拶してまわってきました。毎年年度末は忙しく、夏は暇。そんな時期があったのに、最近は夏も忙しく、年度末は例年通り忙しい。そんな普通の会社になってきて、そろそろ休憩できる時間も計画的に創っておきたいな、と思うこの頃です。というわけで、溢れすぎた時に頼れるパートナー企業さん探しもかねて、行ってまいりましたよ。丁度大場が宮崎に帰省するということで、それにくっついていくかたちで。

#少し前の活動ですが弊社の雰囲気を見にこのサイトを訪れてくれる方々もいらっしゃるので、忘れないうちにう記事を公開しておこうかな、と。

会社~空港

2016-03-23_081743022_98F90_iOS

2016-03-23_081748315_DF0CC_iOS

2016-03-23_093535470_28138_iOS

宮崎周辺

2016-03-24_011804003_B944A_iOS

2016-03-24_022355729_6D08F_iOS

2016-03-24_042518686_63A23_iOS

福岡周辺

2016-03-24_142221000_69564_iOS

2016-03-24_160905486_F5EC5_iOS

2016-03-25_032610584_12DE9_iOS

大分周辺

温泉地めぐったんだけど、なぜだか写真が見つからない。また次回、すかね。

Viewing all 2941 articles
Browse latest View live