「マイグレーション」を含む日記 RSS

はてなキーワード: マイグレーションとは

2017-10-12

京都市が今回失敗したような、自治体システム更新について

http://itpro.nikkeibp.co.jp/atcl/column/14/346926/101101158/

Q1.役所仕事なんて全国でほぼ一緒なのに、なんで自治体ごとに別のシステムを作るの?

A1.地方自治体事務財務について法律で決まっているのは大枠だけだよ。

  それを実務≒内部規定に落とし込むのは各役所ごとなので大枠は似てても実務プロセス全然役所で違うよ。例えば同じ業務でも独自の語彙があったり、下手すると同じ語で市町村ごとに意味が違ったりするよ。


Q2.なんで新規で作らないの?

A2.80年代ぐらいにやったよ。その結果が政令市クラスに残ってて今回京都市更新しようとしてるような、メインフレーム上のシステムだよ。


Q3.メインフレーム汎用機)って何?

A3.みんなが使ってるWindowsとかLinuxとかのOSがなかった時代コンピュータだよ。IBMとかがベンダーごとに作っていてOSベンダー謹製だよ。性能はいいけどメチャ高いよ。

システム内でクローズして専用線以外では他とつながってなかったから、汎用機からPCサーバへの移行を「オープン化」と言うよ。

オープンソースソフトウェアとは全然関係ないよ。


Q3.使いまわしってどうやってやるの?

A3.80年代かに作ったシステムで動いてるCOBOLとかPL/IとかをLinuxとかUnixとかWindows上で動く言語コンバートしてリコンパイルするよ。

DBデータ階層データモデルからリレーショナルDB用にコンバートして移行するよ。こういう開発形態を「マイグレーション」と呼ぶよ。

あと、バッチジョブ制御もJCLという汎用機用の言語で動いているよ。これもそのままでは動かないのでコンバートするよ。

コンバート先はperlだったり、シェルスクリプトだったり、ベンダごとの独自スクリプトだったりするよ。

COBOLとかの実行プログラム移行も大変だけど、帳票の大量印刷はたいていバッチジョブでこなしてるので、JCLの移行もめちゃ厄介で大抵もめるよ。

今回もめたのもバッチらしいね


Q4.80年代のものを使いまわすとか。新規で作ればいいじゃん

A4.お金無限にあればできるよ。今の時代お金があった時代システムフルスクラッチ再開発するととんでもない予算になって市役所内の決裁が通らないよ。

しか汎用機時代の納品は割といいかげんだったのか、仕様書が残ってなかったりするから費用さらにかさむよ。


Q5.そんなんでよく運用できてたな

A5.当時はSE汎用機付属品みたいについてって、困ったらオペレーターとして介入して動かしていたみたいだよ。

そうやって現場感覚バリバリでやっているので、オペレーターしか知らないプロセスがあったりするよ。

マイグレーション開発では総合テスト中にそういう隠しプロセスが「発見」されたりするよ。こわいね


Q6.役所が現行システム資料を出すべきだろうが!

A6.もっともだけど、できないから無理だよ。

上記の通り仕様書がないことも多いうえ、システム課に限らず市役所人員は基本ローテーションするよ。

導入当初の担当者が残っていることは珍しいし、30年も前に導入した汎用機ことなんてここ10年に入った職員にはわからないよ。



Q7.なんで入札にしたの? 現行ベンダ指名してやらせたほうが良くない?

A7.金額がでかいから、たぶんどこの市役所でも入札案件だよ。

随意契約(随契)は無理だし、入札業者発注者指定する指名競争入札談合の温床になってたか最近あんまりやらないよ。


裏技としてRFP指名したいベンダーに書かせて公募指名入札にしたり、RFPの段階でハードを全部特定ベンダで型番まで指定するというのがあるけど、公になると多分問題になるよ。こわいね



Q8.じゃあ役所は悪くないの?

Q8.悪いよ。

入札案件RFPで書かれた各項目をどれだけ満たすかの技術点と、価格点で決まるよ。点が高ければだいたい自動的にそのベンダーに決まるよ。

なので、技術点の項目に現行システム調査にかかる項目を入れるとかして、現行機の開発・保守ベンダ高得点を取れるようにしておけば価格勝負してくるベンダーをはじけた可能性はあるよ。

もちろん現行の会社に嫌われて逃げられたとか、役所が現行の会社めっちゃ嫌いになって声をかけなかったとかもあるかもしれないけれど、可能性は低いと思うよ。



Q9.じゃあベンダーは悪くないのか?

A9.ここまで述べたようにこの手のマイグレーション火薬庫だよ。火を噴いても爆発しなければラッキーぐらいなので、強いて言うなら入札したことが悪いよ。

安すぎる見積もりを出したSEだか営業だかは死んでね。



Q10.お前(増田)は何者?

A10.前にマイグレーションをやったことがあるSEだよ。もうやりたくないよ。今は転職してSIerじゃなくなったからやらなくてよくなったよ。うれしいね

  しょぼいSEからここに書いたことは個人体験に基づく参照情報だよ。一般的じゃないことを言ってたり、間違ってたら教えてもらえると助かるよ。





(2017.10.13 追記)

Q3がかぶっていたよ。恥ずかしくてなきそうだけどブコメに番号で言及してくれている人がいるから忍んでそのままにするよ。


あと、「オープン化」の定義が違くない?という指摘があったよ。確かに増田が間違っていたので、記事の主旨から外れるけど補記するよ。

メインフレームは本文で述べたようにOSからハードまでメーカー謹製なので独自仕様のカタマリだよ。

これに対しPCサーバ標準規格で作られているよ。こういう標準規格に基づくサーバオープン系と呼ぶよ。

独自規格クローズしたコンピュータから、そうでないオープン系に移行するからオープン化なのであって、専用線とかは関係なかったよ。半可通な知識で語ってしまったよ、ごめんね。

京都市で火中にいるシステムズさんのサイト解説がこの増田よりも分かりやすくて正確だから気になる人は見てほしいよ

http://www.migration.jp/column/column01.html

完全に余談だけどオープン系のx86サーバに移行しても、システムはそんなにオープンにならなかったりするよ。

H系に頼むとDBが拝承DBになったり、Fに頼むとシステム管理が全部SystemWalkerになったり、要するにベンダ独自のミドルに入ってがっつりロックインされたりするよ。

オープン化(オープンではない)みたいなことになって面白いよ(面白くない)

2017-06-24

プログラマー技術力とは

やっと理解したけど、出来るだけコードを書かないことなんだな

GitHubでいい感じのライブラリを見つけて、sqlマイグレーション

サーバーレスコンフィグ設定もせず ほぼせず

スケーラビティawsEC2クラウドフロント、S3使っていいかんじ

AIAPIでなんとか

シコシココード書くのは古くなった感じある

2017-03-08

Railsつらい

バージョンアップがツライ

毎度毎度、バージョンアップで非互換修正加えてコード修正必要になって、Gemも上がって依存が壊れて

いつまでやってんだよw

Railsプロジェクトでどれだけの人が最新版追従できてんだよ?テストを書いてれば余裕?

本当かよ?正直に言ってみろよ?実際はレガシーRailsの山だろw

概念・周辺ツールがツライ

ヘルパーやらマイグレーションの仕組みやら最初は良いかなと思ったけど、どう考えてもやり過ぎだ

短くかけるとか喜んでるやつは一度考え直せ

複雑さがRails側に寄ってるだけでなんも解決してない

それで良いんだって自分コントロールできない知らないコード依存して結局バージョンアップ地獄みてるだろw

最低限中で何が起きてるか理解しとけよwまあ理解できるころにはRailsでなくても良かったんやwってなるけどなw

RAILS_ENV=productionだとstaticファイル自分で返さないassetコンパイルで小さくしましょう

→ developmentで動いてたけど本番だと動きませんでしたw

どんな茶番だよw馬鹿か?

Gemがツライ

毎度毎度、アホみたいにGem入れやがって、もう自分で把握できる状態じゃねーだろ?

bundlerだから完璧にvendoring出来ますだって

本当かよnaitive extensionGemなんてどう考えたってRails管理外のヘッダファイル依存すんだろ

bundle installがこけるなんて日常茶飯事だろw

環境構築がツライ

ruby入れてGem入れてGem入れるためのヘッダ用意して

めんどくせーなbundlerもこけるし、rbenv使ってrubyバージョン揃えろとか

ホントめどくせーよ

deployもcapistrano便利とか言ってるけれど、そんなに便利じゃねーよw

あんDSL覚える時間あんならシェルスクリプト書けるようになっとけ

rackサーバがたくさんあってよかったねじゃねーよ集約しろ馬鹿

unicorn, puma比較しましたとかアホ記事書いてる暇あるなら集約するかなにかしとけ

信者がツライ

この手の話すると信者が使わない方法もある・選択しない方法もあるとか擁護してくるけど

そりゃあるけどそれ調べんのがめんどくせーって言ってんだよw

何でもかんでもレールに乗せてそれを強要してくるような感じがすんだよw

turbolinksなんて仕組みをデフォルトONにしてくるやつらの態度が嫌なんだよ

2016-12-19

PHPってダサいよね〜イケてないよね〜

あたし、Rubyやってるの。

Ruby on Railsっつーフレームワークね。

まじイケてるから

もうね、全部スッキャッフォッルドでできるし、アクティブレコードだしマイグレーションスキーマロードちゃう感じ。

ジェッムもたくさんあるっていうかー。

デヴアイスとかつかうと、SNSとのオッスウ認証が楽ちんちん

ターボリンクがいけててジエイクエリもすっきり。

最高だよねRails

PHP?だっさーい。東京で言うと八王子みたいな感じ。

2016-11-01

退職なさる先輩へ

近々退職なさる先輩へ、後輩からアドバイスです。

インデントや空白の有無にはきっちり規則性をもたせましょう

タブとスペース混じりのインデントなど、見るに堪えません。

きっちり規則を決めてコードを書きましょう。

Gitコミットメッセージをちゃんと書いてください

updateやfixなど英語単語だと何が変更されたのか非常にわかりにくいです。

あと職場英語圏の方はいなかったので無理に英語を使う必要はないと思います

手動でサーバを構築しないでください

環境再現することやサーバの中身を把握するのが困難になります

世の中にはAnsibleやItamaeなど便利なプロビジョニングツールがあるので是非使ってみてください。

手動でDBスキーマを変更しないでください

開発環境と本番環境で食い違いが生じてエラーが発生していましたよね。

DBマイグレーションツールを使うのをオススメします。

N+1問題などボトルネックになりやすい部分は気をつけましょう

キャッシュを設けても遅くなるものは遅くなるのです。

クエリの発行数や計算量など意識してみてください。

エラーが直ったかどうかはきちんと確認してください

動くかどうかも確認せずに「直ったよ」と嘘をつかれても他人迷惑しかなりません。

テストコードを書ければ良いのですが、最低限手動でもいいのでご自分確認してください。

コードドキュメント仕様は一致させてください

利用する側の人はドキュメントを見るので実際の挙動と異なっていると困惑します。

整合が起こらないように気をつけてください。

HTTPステータスコード意図にあったものを返しましょう

GETしただけなのに201を返すなど意図にあっていないものがありました。

ステータスコード意味を調べてよく考えてみてください。

他にも言いたいことは沢山ありますが、あまり長くなるのも迷惑かと思うのでこの辺でやめておきます

先輩は技術知識はたくさん持ち合わせていましたが、どうにも技術的に他人を思いやる文化を持ち合わせていなかったように思いました。

上記の点を直すことによって、そういった文化を養うことがエンジニアとしてのステップアップにつながるはずです。

次の職場でのますますのご活躍をお祈り申し上げます

2016-09-24

PHPってダサいよね〜イケてないよね〜

あたし、Rubyやってるの。

Ruby on Railsっつーフレームワークね。

まじイケてるから

もうね、全部スッキャッフォッルドでできるし、アクティブレコードだしマイグレーションスキーマロードちゃう感じ。

ジェッムもたくさんあるっていうかー。

デヴアイスとかつかうと、SNSとのオッスウ認証が楽ちんちん

ターボリンクがいけててジエイクエリもすっきり。

最高だよねRails

PHP?だっさーい。東京で言うと八王子みたいな感じ。

2016-08-03

光回線がこなくて発狂しそう

2016年にもなってなんでこないの!役場に聞いても無理ですねじゃなんだよ!

光の道はどうなったの?

PTSNマイグレーションは?

なんでもいいからはやくFTTHきなさいよ!!!

2016-07-21

PHPってダサいよね〜イケてないよね〜

あたし、Rubyやってるの。

Ruby on Railsっつーフレームワークね。

まじイケてるから

もうね、全部スッキャッフォッルドでできるし、アクティブレコードだしマイグレーションスキーマロードちゃう感じ。

ジェッムもたくさんあるっていうかー。

デヴアイスとかつかうと、SNSとのオッスウ認証が楽ちんちん

ターボリンクがいけててジエイクエリもすっきり。

最高だよねRails

PHP?だっさーい。東京で言うと八王子みたいな感じ。

2016-05-17

40代後半以上のプログラマは糞

CTO含む

人によるとは思うけど、俺が関わった会社プログラマの年齢の傾向から言うと全員あてはまる。


理由

過去の栄光を引きずり過ぎ

過去にそれで納品したか、褒められたかしらないけど、遺物を自慢しすぎ

今の時代にそぐわないプロダクトや、フローを自慢気に話されても何の得にもならない

自動化とか意味ないでしょ、ドキュメントありゃ誰でもできるよ、DBマイグレーション?めんどくせえ、スキーマダンプ管理しろよ」

はあ?どんだけ時代に逆行してるんですか?CTOがそれいっちゃオシマイでしょ。時代の流れ読めないの?

そう言ってるヤツのおかげでどんだけチームが苦労してきたと思ってんだよ


PHPとか誰でもできんだからフレームワークかいらないでしょ、そんなの使わずにスピーディに仕事しろよ」

はあ?ひとりでやってろよ

口は達者だけど、svngit 使えない。svn も使いたくないけど。

誰かの書いた独りよがりコードのせいで、リリースはだいぶ辛かったりする。

それが最近自動化や、フレームワークのおかげで、リリースの負荷は軽減されてる。それを全然鑑みないのはマジでクソ。


技術力はひと昔前のトップクラスなのかもしれない(多分そうではないと思っているが)が、マジで迷惑

属人的な要素を排除しようと、自動化CIヒューマンエラーを極力抑えても、俺様一言でまたプロジェクトが壊れる

マジでお前それでどんだけ金もらってんだよ、邪魔しかねーし、口だけは達者だから金ももらってんだろうな

ほんと個人攻撃したくないけど、老害死ねばいいのに

2016-03-22

いつになったらADSL並の値段で光回線が使えるのか

スマホと合わせて月2000円引きです!乗り換えませんか!じゃねえんだよ。

どんなに見積もってもADSLより月1500円以上高いんだよ。

なんとかマイグレーションで切り替わるんじゃなかったのかよ。

2015-10-02

RapidSiteのマイグレーション

RapidSiteのマイグレーションで約1ヶ月てんてこ舞いでした。

これまでRapidSiteでは米国NTT/VERIO社という所が提供元だったようです。

これ自体がそもそも知らなかったんですが。

んで、今回、NTT/VERIO社がサービス提供終了を決定した事で

RapidSiteで自前でサーバーを構築する事になり

それに伴い、ほぼ全てのサービスで、サーバー移動が発生した。

との事。(あくまネット上での情報ですが)

自社で管理しているサイトで、このラピッドサイトVPS上に

ドメインを切り管理していました。約11サイト

置いていたサイトは、静的だったり、単純なWPだったので

サイトデータ移行自体はそんな手間では無かったです。

というか、サイト移行自体はRapidSiteの方でやってくれました。

まぁこの移行方法もどうなんだよって感じだったんですが後述)

んで、何が一番の問題だったかというと

メール”と”DNS

もうこれで死にかけました。

まず、ドメイン11個なのですが、その中に複数メールアドレスがあり

最終的には、何百というメールアカウントを設定しなければなりませんでした。

メールアカウント自体も、新サーバーにそのままRapidのほうで移行されたのですが

結局DNSの切り替えのタイミング等もあり

サーバーメールアカウント

サーバーメールアカウント

をそれぞれ、設定しなければなりませんでした。

ある程度、リテラシーのあるお客さんであれば、コレコレこうだから

メールアカウントを重複して登録してくださいね。とアカウントリストとともに

メールサポートぐらいで澄んだのですが

今回、Rapidに入っていたお客さんは、自分がこの会社に入る以前から

付き合いがあったであろうお客さんで、割とパソコンの設定からサポートとしているような

所ばかりでした。

何百というメールアカウントの再設定…

もちろん走ったのは営業さんでしたがもうコレで本当に胃をやられました。

Rapid側の手順やサポートの不確かさ。

この11ドメインが入ったサーバーの他、もう一つ

単体で動かしているサーバーもありました。こちらのサーバー

先に移行という事だったのですが

移行完了しました!

というメール確認し、実際に見てみると

何も移動されていない…

完全に空っぽ状態でした。

というかまず、移行完了メールもなんか文字化けしまくりで読めないし

(これはこっちの環境のせいなのか??)

そのことを電話で問い合わせると、Rapid側の手違いで

移行ができていなかった事が発覚。そちらが宜しければ

再度移行作業をすぐ始めます!とのこと。

データコピー時に既存サーバーは停止していました。

しかも平日の真っ昼間から

自社のお客さんには、予め停止する事を断っておく必要があるため

Rapid側で作業が改めて行える日を教えてください。と返すと

そこから1ヶ月近く連絡無し。

えぇぇ…(汗)さすがに不安になり再度問い合わせると

日程は追って連絡致します!の一点張り

おいマジで大丈夫なのか???(滝汗)

その後、一応移動はされたのですが

完了メール記載されている、新コンパネアドレスが間違っている等

とにかく全体的にアレな状態でした。

FAQのわかりにくさ。不確かさ。

今回のマイグレーションに関して、Rapidのサイトにて

FAQが設置されているのですが、これまた分かりづらい。

ほぼ全てのサービスだったため、それぞれの移行FAQが設置されているのですが

似たようなサービス名でいったい自分がどれに該当するのかが良く分からない。

また、そのFAQリンクが切れていたり

記載内容がページとメールとで案内が違う等

とにかくカオス

ネームサーバーわかりづらさ。

今回これが一番の問題でした。これは一応上記FAQをしっかりと読みこめば

回避出来たかもしれない…

ただ、上記のようなカオスFAQ鵜呑みにしていいのか?!とか心配込みで。

今回、自社では

サーバーはRapidで管理し、ドメインはお名前管理をしていました。

今回の案内で、ドメインを他社で管理している場合ネームサーバーの変更が必要です。

と案内されていました。

これを自分

ドメイン側で設定をしない限り、新サーバーに向くことは無い。

勝手解釈してしまっていました。

これが間違いだった…。

PCのhostを書き換えそれぞれのサイトの動作チェックをしていたのですが

「あれ、ホスト書き換えて無いドメインなのに、こいつ新しい方向いてね…?」

ここで一気に分からなくなりました。

何故、ドメインの設定を変更していないのに、すでに新しい方を向いているのか?!

サポート電話をしても、マジで1日中出ない(カケホ端末からマジで1日かけっぱでも)

まず「ドメイン側で設定をしない限り、新サーバーに向くことは無い。」という認識だったため

この時点でメールの設定は行っていませんでした。しかしポツポツとお客さんから

メール不具合が上がってくるようになり、その後、一気に炎上しました。

もうこの時点で、自分も一体どんな状況なのか、まったく分からなくなりました。

頼みの電話サポート無慈悲なマシーンボイスが響きわたるのみ…

電話を諦め、メールで問い合わせました。

ただメールも1日1回ぐらいの頻度でしか帰ってこない…

泣きそうでした。

分かりにくい。本気で分かりにくい。

よくFAQを読んでいなかったのもあれなんだが

まず、前回のサーバーログインを間違えて送ってくるようなメールを信用出来たか

こちらでメールアカウントを、必ずテストをしてからじゃないと信用出来ないじゃないか。

電話サポートも通じない状態で、こんな力技なサービス移行ってありなのか?

まずデータ移行(サーバー停止)も、11時~23時ってなんで日中の真っ昼間からなんだよ!

なんか、極力ユーザーに手を煩わせないようにという

「考え」は感じるのだが、それを行うためのサポート体制や正確さが

全くと言って水準が低いと感じました。。。



別件ですが、同GMO系列のお名前でも、VPSサーバー移行知らせが届きました(ドクロ)

どうやらお名前の方は、Rapidよりも期間の短い21日で移動しろや!

との事(しかCMSを使ってたらデータ移行もユーザー責任で)

修羅の国を超えたと思ったらまだ修羅の国でした。助けて。

2015-01-16

http://anond.hatelabo.jp/20150116173108

発注を受ける側に立ってもそうだろ。

2020年で無くなる技術を使用したソフトウェア開発」の依頼を受けても経験にならんしデメリットばっかでいやだろ。

マイグレーションを込みで発注貰えるなら別にいいんだろうけど、OpenCVとかを見積もるのはきついぞ)

ってか、サポート期限までの折り返しに立ってこれってことは、pythonって実は学ぶべき言語じゃないってことなんじゃねーの?

なんでみんなpython3に移行せえへんのや…

2014-08-12

http://anond.hatelabo.jp/20140812115457

どうせそのプロジェクトマイグレーションの役目も含んでいるなら、最初のうちにレガシーをつぶしちまう方がいいだろ。

テストしてるうちとかに非互換が出てきたときのほうが悲惨だぞ?

2014-02-28

去年はじめから現在まで

2013年1月か2月

プログラミング経験、ほぼ皆無。

HTMLCSS, JavaScriptちょっとだけ分かる

dotinstallとか見てブラウザタイマー作ってわーいって喜んでるくらいのスキル感。

プログラミング勉強したい

勉強したいけどスクールとかはお金かかるから嫌だ

→本を買ってやるのは安上がりだけど途中で挫折しそう

→じゃあお金稼ぎながら学んだらいいんじゃ

プログラマバイト探そう

求人サイトで見つけて応募してみる

経験でも大丈夫らしい

バイト始めることになった

バイト始まる

はじめは研修アルゴリズムPHPについて

課題を出されて、できたら業務に入れる

フレームワーク使って指定されたwebサービスをつくる

基本自分の力でつくる。放置される

誰も教えてくれない

今思うと初心者やらせるのはなかなかハード

ググってググってググりまくる

他のできる子はさらさらっと1週間くらいで終える

ひーひー言いながら2~3週間でなんとか終えた

この期間、ほとんどプログラミング以外のことしてない

なんとかなった

3月4月

PHPドキュメントを読む習慣がつく

ググってコードコピペして動かしてみる、という段階

動くと楽しい 分かると楽しい

このときくらいにパーフェクトPHPを読んだ。FWは、つくれる!

FWがなんたるかをやっと理解し始める

あーようするにURLを受け取って振り分けたり、DBからデータ引っ張ってきて画面に表示させたりするのね

分かった気になる←分かってない

HTTPリクエストについて気にしだした

GET/POSTでごにょごにょすればいいんだね楽勝だわ←全然分かってない

フレームワークはいくつも種類があることを知る

このころ、Sinatraという言葉を小耳に挟む。支那虎?

5月6月

FuelPHPを聞きかじって、何をトチ狂ったのか在宅でwebサービス受託をやる

まあ良い経験になった

フレームワークいくつかやって、web開発のいろんな概念tipsがたくさん頭に入ってきて、

あーあれかーくらいには思えるようになった

DBCRUD操作, ORM, DBマイグレーション, RESTfulとは, コマンドラインコード生成,認証周りのプラクティス ...

7月くらい

さて、バイトが本格的?になってくる

一人で開発 責任おもい

機能追加のタスク

ごく一般的機能

でもなんか躓いた。

書いたコードに自信が持てない

これでいいのか不安になって手が進まない

やっぱり自分で考えて経験したことのないことはなかなか難しい

DBのテーブル構成を理解するにも骨が折れた 命名規則大事

セキュリティで手直しはたくさんもらった

フレームワークにはDB操作ライブラリがちゃんとついてるのにそれ見ずに自分SQL組み立てて案の定エスケープしてないし、とか

必要ないところでCSRF対策してるし、とか

でも、なんとか完成させた

プッシュして、マージされて、できちんと本番環境で動いてる。やったね。

8月9月

Rubyを知った

PHPと違って()が殆ど無いし、;ないし、do~endとか何だよって感じだった。

ちょっとだけ触ってみた。使いやす

Railsも知った

それからは空いている時間の大半をRubyRailsにつぎ込んだ

まずはRailsTutorialをやってみた

テスト周りでつまづいたけどなんとか終わらせた

dotinstallやらミニツクやら、検索して出てきた記事・チュートリアルはとりあえず手をつけて学んだ

はじめはRuby理解せずにRailsをやっていたけど、すぐにRuby自体に興味が出てきた

はじめてのRuby・はじめてのプログラミング・たのしRubyプログラミング言語Ruby... 入門系の本を乱読した

PHPでさんざん苦労していたからか、Rubyオブジェクト指向を学ぶとなんの無理もなく頭に入ってきた

Rubyドキュメントの読み方を覚えた

その後、パーフェクトRubyで標準ライブラリやらGemやらSinatra支那虎じゃなかった)やらについて学んだり、

メタプログラミングRubyで黒魔術を学んだりした。巻頭のMatz言葉痺れたなー

バイトのほうも何とかこなせるようになってきた 成長すげー

9月10月11月

Vagrantをかじる

インフラ・ミドルネットワーク周りに興味がでてくる

AWSでいろいろ遊ぶ

メタプログラミングRubyは断続的に2~3回ほど読み返す

Rubyってほんと使ってて楽しい

webスクレイピングとか検索APIとか使ってムフフ画像をアハーンしたりして遊んでた

11月12月

Rubyと名のつく書籍を読みあさる

Ruby言語をつくろうだの、スクリプティングを極めようだの、JavaRubyがどうだの。

メタプログラミングだの、デザインパターンだの、テストだの、リファクタリングだの。

借りられる本は借りて済ませた。全部買ってると破産する

他にもRubyとつかない本もいろいろ。

達人プログラマーは途中で挫折した。そのうちもう一度読む

プログラマが知りたい97の何とか。いい本

Ruby関数オブジェクトからのつながりで関数型プログラミングにも手が伸びる

OOPと全く違う。

2014年1月2月

就活はじめるよー

まあ、エンジニア枠で探すことにする

エントリーめんどくさい

ので、1社受けて落ちたら次の会社エントリーするという作戦にした

無計画玉砕作戦

はいえ、なんとかなると思ってやってく

気を揉む期間

いろいろな会社採用ページ眺めていると気になること

入ってやる仕事の内容が分からない

やたらパララックスつかってゴテゴテにしてるわりに、何が言いたいのか伝わってこない

せめてよく使ってる言語くらいはのっけておいて欲しい。

気になる会社はいろいろ調べる

で、1社選んで応募して、選考が始まった

面接、失敗したなと思ったところもあったが

嘘つかない

知らないことを知ってるように話さな

は通せたので良かったと思う。

で、進んでいって最終面接。これもなんかよく分からないうちに終わってた

相手が適宜フォロー入れて話しやすいようにしてくれたのは覚えてる

うん、ぜひ当社にご入社いただけたらと思いますとのこと。やったね。

から気になってた会社ではあった。勝手リスペクトしてた会社

自分が憧れてる技術者さんたちが在籍してる会社でこれから働くことができる

いろいろと運が良かった。嬉しい

他の会社はどうしようかな。

受けてみたい気もするけれど、エントリーがめんどくさい

続けるかどうかは未定だけど、ひとまず休憩することにする

今は、関数型言語についての本買って読んでる。関数型、Rubyに劣らず楽しい

2008-12-26

[][]Rails of Ruby on Rails ~Case of LOCUSANDWONDERS.COM~

Blog locus.heroku.com

Products locus.heroku.com

Rails of Ruby on Rails サポートサイト

http://railsofrubyonrails.com/download/locus_files.zip

LOCUS. AND WONDERS.

Heroku | Cloud Application Platform タグ「heroku」を含む新着エントリー - はてなブックマーク

BitNami :: RubyStack

BitNami :: From InstantRails To RubyStack

BitNami :: Redmine

Amazon.co.jp: Rails of Ruby on Rails ~Case of LOCUSANDWONDERS.COM~: Plan de Sens, 清水 智雄: 本

ブログショッピングサイト作成ケーススタディを解説します。

音楽サイトを選んだのは、画像、音声、動画など、

今のWebで考えられるほとんどのコンテンツを扱っており、

Railsの良さを一番実感していただけると思ったかです

Ruby on Rails 2.0対応

「レイルに乗ってみた」の検索結果一覧 - 牌語備忘録

「Rails of Ruby on Rails ~Case of LOCUSANDWONDERS.COM~」を含むブログ - はてなキーワード

満足せる豚。眠たげなポチ。:RAILS OF RUBY ON RAILS が実にすばらしい件

RAILS OF RUBY ON RAILS - 世界線航跡蔵

いろんな意味で新しい Rails 本: Rails of Ruby on Rails - まちゅダイアリー(2008-05-24)

Rails of Ruby on Rails 目次

Rails of Ruby on RailsCase of LOCUSANDWONDERS.COM~

Introduction

 HTMLCSSからその先のステップ

 Ruby on Railsの基礎知識

 プログラミングRubyの基礎

Chapter 01 開発環境構築

 Windowsでの環境構築

 Mac OS Xでの環境構築

 Windows / Mac OS X共通の設定

Chapter 02 プロジェクト作成

 Rails プロジェクト作成

 データベース接続の設定

 データベース作成

 データベースの内容を確認する

 開発用Webサーバの起動

Chapter 03 ブログ作成

 記事の作成・読み出し・編集・削除

  スキャフォールドジェネレータで管理画面を作る

  レイアウトを変更する

  各ページのデザインを変更する

 バリデーションと日本語対応

  バリデーションを使ってフォームの入力内容を検証する

  Ruby-GetText-Packageをインストール

  バリデーションエラー日本語化

 ユーザ認証管理

  ユーザー認証機能を付ける

 画像アップロード

  FileColumnプラグイン

  マイグレーション

  モデルの修正

  フォームの変更

  画像を表示するようにViewを修正

 フィードAtom)を配信

  Atomフォーマットを追加

  Atomフィードテンプレート

  Auto Discoveryを追加

 コメント機能

  ベースを生成

  マイグレーション

  モデルの修正

  ネスティッドルート

  コントローラの修正

  コメント機能を記事に組み込む

 トラックバック機能

  スキャフォールドでベースを生成

  マイグレーション

  モデルの修正

  ネスティッドルート

  コントローラの修正

  トラックバック機能を記事に組み込む

 タグタグクラウド機能

  プラグインインストール

  記事にタグ付け機能を追加する

  タグクラウド表示をサイドバーに追加する

Chapter 04 ショッピングサイト作成

 商品管理

  商品管理

  ジャンル管理

 ショップ画面

  商品一覧画面を作成

  商品詳細画面の作成

  ライトボックスJSライブラリを使って商品画像を効果的に見せる

 ショッピングカート

  Cartモデル作成

  CartItemモデル作成

  Cartコントローラ作成

  カート画面の作成

 注文処理

  OrderモデルとOrderItemモデル作成

  決済・注文画面の作成

 自動返信メール

  メール送信のための設定

  メーラージェネレータでOrderMailerモデル作成

  送信内容のテンプレート作成

 コンタクトフォーム

  メーラージェネレータでContactモデル作成

  フォームの作成

  入力の検証をする

Chapter 05 サーバー環境

 Railsアプリケーションの公開

  Herokuを設定する

  アプリケーションを公開する

  サイトを本番運用環境に変更する

Chapter 06 ユーザー事例

 ケース1 Saigenji (http://saigenji.com)

  サイト携帯電話対応にしたい

  インタビュー

  作品集 (Saigenji & Happiness Records 編)

 ケース2 UK.PROJECT (http://ukp-pr.com)

  Railsインクリメンタルサーチ

  インタビュー

  作品集 (UK.PROJECT 編)

 ケース3 Traffic (http://trafficjpn.com)

  動的データを静的ページに表示したい

  インタビュー

 ケース4 RX-RECORDS (http://rx-records.com)

  複数の画像が切り替わるFlashバナーRails管理・生成したい

  各バンドごとに情報を集約させたい

  インタビュー

  作品集 (RX-RECORDS 編)

 ケース5 石田ショーキチ (http://scudelia.net)

  ラジオ番組ポッドキャスト形式で配信したい

  通常のページ構成以外の特設ページも管理したい

  サイトの好きな場所にバナーを設置・管理したい

  インタビュー

  作品集 (石田ショーキチ 編)

 ケース6 V2 Records (http://v2records.co.jp)

  Wordのような操作感でニュース記事を編集したい

  情報を限定し直感的で簡単に管理したい

  インタビュー

 ケース7 橋本昌彦 (http://www.hashimotomasahiko.com)

  天気と連動した画像を表示する

 ケース8 BUMP OF CHICKIN (http://www.bumpofchicken.com)

  拡大画像ロールオーバーで表示したい

  インタビュー

  作品集 (HIP LAND MUSIC 編)

 ケース9 Cradle (http://cradleorchestra.com)

  見たい記事だけをアコーディオン表示させたい

  インタビュー

  作品集 (Cradle & Palette Sounds 編)

Appendix

 主なエラーの例と対策

 Reference

2008-07-21

http://anond.hatelabo.jp/20080720184208

■さて、官公庁ユーザとしてどうするのが適切なのだろうか。

百兎通信さま[[雑談]他人の努力にきたいする人]

http://d.hatena.ne.jp/isayama/20080720/1216562529

キレイにまとめららていて、また当方の耳に痛いことも進言してくださいました。ありがとうございます。

事実とか思いとか、「日立製作所」の問題か「官公庁のIT調達」の問題か、といった部分がないまぜになって単なる愚痴っぽい文章に終わっていますね。読み返すと。読者のみなさん、申し訳ありませんでした。

さて、内の組織日立製作所を始めた大きな組織が急に体質を変えて、適正なIT調達と技術の適用がすばやく進むとは思えません。日本的なボトム・アップ式のゆるやかな改革の連続が、いつか壁を突き破ることにつながることになるだろうと思います。

私が担当ベースで粘り強く取り組むことは以下のとおりかと思います。

(1)日立メインフレーム見積もりで高い、または前回購入時よりほとんど下がっていない点については徹底的に説明を受け、当方の組織に納得できるよう資料を提示してもらう。

 ・以前、ガートナージャパンの亦賀ヴァイスプレジデントが「国産メインフレームの最大の問題は価格不透明さ、そして、今後の技術のロードマップ不透明なところである」と言っていました。

 この点を担当者として、勉強もしながら疑問点を洗い出して、ベンダーにぶつけ、友好的な交渉の後、適正な価格・構成で契約すべきでしょう。

 疑問点の洗い出し(「なぜ」を何回も繰り返す)

・1プロセッサーあたりの処理能力は向上しているのに、IBMのように筐体統合論理分割=LPAR)を推奨案とせず、メインフレームの台数が多い構成を薦めるのだろうか(秦野市ハード工場の維持のため台数出荷は押さえておきたいポイントなのか)

・1プロセッサー(50MIPS程度)で提供価額1億円を超えており、明細がないが説明をしてもらう。

 プロセッサー単体=1億ではなくある程度パッケージ化された固まりなので1億円の大台になってしまうのだと思う。交代用プロセッサー、SVPと言われるプロセスを監視する機構、あとメモリ(4G)等いろんな部位があってこういった値段になっている。福袋のようにまとめて、1億とか言われると思考停止するので、ここは明細を出してもらい、サービスマニュアルでどんな働き、冗長性を持っているかを理解して価格交渉するべきですね(デカルト「困難は分解せよ」)。

・詳細な見積もり書の提出を日立が拒む可能性は大きい。これまでも数度にわたり交渉したが、先方は牛歩作戦でうやむやにしてきました。ここは企業企業なので、いろいろ駆け引きもあるようですが、地道に交渉します。気の利く営業マンだと「今の時点では正式な紙としてお出しできませんが、口頭ベース未確定でメモをお取りいただいたということで・・・」と言って企業名の入っていない内訳メモを出して、こちらの気を揉ませることのないよう配慮するのでしょうが。

・CPU周辺部品の明細徴求

メインフレームは入出力用のチャネルと言われる部品も一個250万円ほどしてそれが、何十個と搭載する必要となるとすごい金額になります。昔メタルチャネルで、その次は光ファイバチャネル、そして最近光ファイバ多重チャネルと何種類かの接続機器が混在し見積もり金額が高くなるのです。周辺機器も順次、上位の接続規格にグレードアップしていけば、統合・集約ができるのですが、どうしてもレガシー接続方法が残ってしまうのですね。パソコンに喩えるとUSBみたいなものですが、高いうえに融通が利かないのです。また、ここは日立独自の技術というよりIBMから技術供与を受けているみたいですね。日立物流トラックから当該部品が入ったダンボール箱の荷下ろしを目撃したのですが「IBM ESCON」と堂々と箱に書いてありました。光多重チャネルは24多重まで可能であるので、数は減らせるはず、減らせないなら納得のいく説明をもらう。また、下位のレガシーチャネル周辺機器の入れ替えの関係もあり1年も使わず廃棄といった勿体無いことがおこりそうです。

 日立グリーンITを推進しているので、自社検証センターや共同システムセンタでさほどクリティカルでない場所でセカンド・ユースして下取りすることは可能か聞いてみます。

・CPUとサーバ間の接続

 最近CPU専用のプロトコル日立ではXNFという)をTCP/IPに変換するホスト側のミドルウェアが実装され、サーバへのデータ転送はFTP転送で可能になりました。メインフレームには内蔵LANアダプターというギガビット・イーサーを搭載でき、またこれが2ポートついているのですが、1個200万円するんです。もっと高かったかな。それでサーバー接続するのですが、普通、複数のサーバとやり取りするならば、中間にスイッチを置いてメインフレーム側のLANアダプターの数は抑制しますよね。

 日立技術者はめっきりネットワークに弱く、サーバと1対1通信をするため、相手のサーバの数だけ内蔵LANアダプターを買わせようとしているのです。メインフレーム側の仕様かなと思い日立メインフレームXNF/TCPマニュアルを精読すると1つのLANアダプターに64個までのLANの設定定義が可能となっていました。でも「ネットワークは自分の専門でないから・・・」等々言って動きたがらないのです。しかし、ここはしっかりお願いをして、場合によってはネットワークに強いベンダーさんを読んで帯域制御なり、VLANなりの十分汎用化した技術を使って最適な構成をやってもらおうと思います。

 

 他の日立ユーザさん、どうですか。ネットワーク接続で目茶苦茶原始的な接続設計で高いハードをたくさん買わされていませんか。こういうハードロット生産なので本社から在庫があるので、少々言葉は悪いけど無知ユーザにはハードを売り捌けという指令が飛んでいるのかもしれません。

■内容不明なシステム保守

 日立はこれを「AP保守料(サービス料)」と読んでユーザ契約させ、1ヶ月毎払いで年間数億円請求しています。当官庁のサイトには常駐のSEさん、ハード保守の人に100人とまではいかないけど、詰めてもらってその方たちには、その保守料とは別に人月ベース人件費を払っています。このAP保守料は何か「本社への上納金」のような気がして仕方がないのです。すべてのユーザがお支払いしているのかも不明なので、いったいどういうものか質問してみます。ユーザサイド常駐SEがいて、それとは別に事業維持のため上納金が欲しい。けれど月々の活動明細は提出しない。資金使途は教えられないというのでは「みかじめ料」みたいですね。日本IBMさんではこの制度はないようです。

■他社への参考見積もり

日本IBM社に同等規模のシステムを構築するといくらくらいになりますか、ということで見積もりを取りました。

ハードの置き換えでなく、使用しているソフト料等のランニング費用を出してイニシャル×ランニングでトータルで参考値を提出してもらいました。

1ヶ月くらいかけて問診シートをもとに結構精緻な資料をつくってもらい日本IBM社には感謝しています。メインフレームは独自ハード、独自OS、独自ミドルといったところで、全面コンバージョンは非常に難しいところがあるのですが、IBMさんは「参考になれば」ということで、しっかりとした資料をまとめてくれました。

 一番、移行に対してハードルが高いのは20年来使っているDBのミドルウェアとのインターフェースが互換性がないということでした。形式が違うため、DBのつくり、アプリケーションから参照するデータ・テーブルを全面改造するとなると、すべてのシステムゼロから書き直すといったことが必要になり、今のこちらの体力では難しいという結果となりました。

 しかし、IBM側もこちらのシステムのつくりを把握することができたので「ここの機能はオープンパッケージマイグレーションするといい」と言った提案は今後してくれるとのことでした。

 印象的だったのは日立のように秘密主義、なにも説明してくれない主義とは違って、自分たちの技術に自信、誇りを持って的確な資料を短期間に纏め上げてきたことです。感嘆しました。また、非売品だそうですが、「IBM Zシリーズハンドブック」という、あまり専門的な知識がなくてもZシリーズイロハが分かる日本語参考書をくれました。これは分かりやすくて、熟読して「日立」には「これはどうなの」と言った質問をしています。顧客に見せるナレッジ・マネジメントという意味ではIBMの方が数段上のようですね。

プログラム使用

 メインフレームプログラムは150種類くらいあって、個別に月々レンタルというかたちで使用料を払っているのです。ものすごく高いです。全部で70千万円くらいかな。価格体系も複雑で、またプログラム種類も多岐にわたり、理解が難しい。これなんかは提供側とユーザ情報の非対称性を「悪用」した「不安商法」といえるかもしれません。でも、税金無駄に使われているかもしれませんので、頑張ってチェックしていかなければ。

■結論■

あまり、味方がいないので、体を壊さないようスケジュールを作ってこつこつ日立製作所との不公正な取引があれば理詰めで解消していきたいと思います。また、他の官庁、自治体で同様な無駄、過剰な契約をしていることがあれば、本当に必要なのか吟味して、全体として適正な方向に向かえばいいと思います。あまり革命は望んでいません。

2008-07-20

http://anond.hatelabo.jp/20080720184208

最初のエントリー書いた者です。トラバの仕方とかよくわからないですいません。

官公庁使用しているメインフレームシステム1980年代通産省コンピュータの国策化を目論む計画もあって、日立富士通に置き換わっていったそうです。そもそも、日立富士通NECは多額の税金補助金として国産メインフレームを作ったという由来があるそうです。それでも日立富士通はIBMへ産業スパイ事件を起こしたりして紆余曲折して現在に至ります。

 1980年代から、税金がらみでコテコテにカスタマズしてしがらみが大きいシステムを作っておき、まともな競争調達ができない状態にして、国民税金を使って多額の対価を得る。調達側も、日立富士通とかに、「安全第一でいくなら、弊社のシステムでお使いになったほうがいいですよ。お酒も奢りますし」と言って勉強不足の状態。

 あまり健全ではない状態が日本のIT力を弱めていると思います。東大東工大大学院を出た優秀な人物が日立に埋もれているという、人材面での弊害もあると思います。まぁ、アメリカと違って、起業家に対する考え方が違うからかもしれませんが。しかし、優秀な人材であれば、日本税金の器の中の小さな技術を引き継ぐだけの仕事をさせるだけでなく、世界競争力を持つ部分に能力をあてがうべきです。

 日立ですが、メインフレーム馬鹿高いのですが、UNIXベースサーバもやたら高いのです。耐用年数が到来して、買いなおしとなるとハード代だけでなく、OS、ミドルウェア等々も全部買いなおしになってしまいます。それは、日立がUNIXサーバを自社技術で確立できず、IBMのAIXやHPHP??UXをOEM提供していて、日立自身が製品提供のイニシアティブをとれないのが原因と思われます。当初、導入した時はそういった説明は一切せず、メインフレームとの接続システムですから、といってセールスしてきました。全国の官公庁ではきっとそういった日立営業の説明を鵜呑みにして「(日立メインフレームの)基幹システムとの連接性が認められる」と意思決定をして、競争入札をせずに、随意契約をしているところも多いのではないでしょうか。

 よく日立の営業の方は「日立は変なところで利益を取ろうとはしていませんから」とか言うのですが、そういった言説こそ間違いだと思います。日立が一般企業と同じく、利益追求を正常に行う企業であれば、世界で勝てる技術開発を行い、他社と互換性があるシステムマイグレーションする道を選ぶと思います。「利益を取ることを考えなくても、税金上がりの金で、そこそこやっていける。その方がしばらくは安泰だ」という考え方があるので、長期的には世界的技術力を失っているんだと思います。

http://anond.hatelabo.jp/20080720184208

最初のエントリー書いた者です。トラバの仕方とかよくわからないですいません。

官公庁使用しているメインフレームシステム1980年代通産省コンピュータの国策化を目論む計画もあって、日立富士通に置き換わっていったそうです。そもそも、日立富士通NECは多額の税金補助金として国産メインフレームを作ったという由来があるそうです。それでも日立富士通はIBMへ産業スパイ事件を起こしたりして紆余曲折して現在に至ります。

 1980年代から、税金がらみでコテコテにカスタマズしてしがらみが大きいシステムを作っておき、まともな競争調達ができない状態にして、国民税金を使って多額の対価を得る。調達側も、日立富士通とかに、「安全第一でいくなら、弊社のシステムでお使いになったほうがいいですよ。お酒も奢りますし」と言って勉強不足の状態。

 あまり健全ではない状態が日本のIT力を弱めていると思います。東大東工大大学院を出た優秀な人物が日立に埋もれているという、人材面での弊害もあると思います。まぁ、アメリカと違って、起業家に対する考え方が違うからかもしれませんが。しかし、優秀な人材であれば、日本税金の器の中の小さな技術を引き継ぐだけの仕事をさせるだけでなく、世界競争力を持つ部分に能力をあてがうべきです。

 日立ですが、メインフレーム馬鹿高いのですが、UNIXベースサーバもやたら高いのです。耐用年数が到来して、買いなおしとなるとハード代だけでなく、OS、ミドルウェア等々も全部買いなおしになってしまいます。それは、日立がUNIXサーバを自社技術で確立できず、IBMのAIXやHPHP??UXをOEM提供していて、日立自身が製品提供のイニシアティブをとれないのが原因と思われます。当初、導入した時はそういった説明は一切せず、メインフレームとの接続システムですから、といってセールスしてきました。全国の官公庁ではきっとそういった日立営業の説明を鵜呑みにして「(日立メインフレームの)基幹システムとの連接性が認められる」と意思決定をして、競争入札をせずに、随意契約をしているところも多いのではないでしょうか。

 よく日立の営業の方は「日立は変なところで利益を取ろうとはしていませんから」とか言うのですが、そういった言説こそ間違いだと思います。日立が一般企業と同じく、利益追求を正常に行う企業であれば、世界で勝てる技術開発を行い、他社と互換性があるシステムマイグレーションする道を選ぶと思います。「利益を取ることを考えなくても、税金上がりの金で、そこそこやっていける。その方がしばらくは安泰だ」という考え方があるので、長期的には世界的技術力を失っているんだと思います。

http://anond.hatelabo.jp/20080720184208

最初のエントリー書いた者です。トラバの仕方とかよくわからないですいません。

官公庁使用しているメインフレームシステム1980年代通産省コンピュータの国策化を目論む計画もあって、日立富士通に置き換わっていったそうです。そもそも、日立富士通NECは多額の税金補助金として国産メインフレームを作ったという由来があるそうです。それでも日立富士通はIBMへ産業スパイ事件を起こしたりして紆余曲折して現在に至ります。

 1980年代から、税金がらみでコテコテにカスタマズしてしがらみが大きいシステムを作っておき、まともな競争調達ができない状態にして、国民税金を使って多額の対価を得る。調達側も、日立富士通とかに、「安全第一でいくなら、弊社のシステムでお使いになったほうがいいですよ。お酒も奢りますし」と言って勉強不足の状態。

 あまり健全ではない状態が日本のIT力を弱めていると思います。東大東工大大学院を出た優秀な人物が日立に埋もれているという、人材面での弊害もあると思います。まぁ、アメリカと違って、起業家に対する考え方が違うからかもしれませんが。しかし、優秀な人材であれば、日本税金の器の中の小さな技術を引き継ぐだけの仕事をさせるだけでなく、世界競争力を持つ部分に能力をあてがうべきです。

 日立ですが、メインフレーム馬鹿高いのですが、UNIXベースサーバもやたら高いのです。耐用年数が到来して、買いなおしとなるとハード代だけでなく、OS、ミドルウェア等々も全部買いなおしになってしまいます。それは、日立がUNIXサーバを自社技術で確立できず、IBMのAIXやHPHP??UXをOEM提供していて、日立自身が製品提供のイニシアティブをとれないのが原因と思われます。当初、導入した時はそういった説明は一切せず、メインフレームとの接続システムですから、といってセールスしてきました。全国の官公庁ではきっとそういった日立営業の説明を鵜呑みにして「(日立メインフレームの)基幹システムとの連接性が認められる」と意思決定をして、競争入札をせずに、随意契約をしているところも多いのではないでしょうか。

 よく日立の営業の方は「日立は変なところで利益を取ろうとはしていませんから」とか言うのですが、そういった言説こそ間違いだと思います。日立が一般企業と同じく、利益追求を正常に行う企業であれば、世界で勝てる技術開発を行い、他社と互換性があるシステムマイグレーションする道を選ぶと思います。「利益を取ることを考えなくても、税金上がりの金で、そこそこやっていける。その方がしばらくは安泰だ」という考え方があるので、長期的には世界的技術力を失っているんだと思います。

 
アーカイブ ヘルプ
ログイン ユーザー登録
ようこそ ゲスト さん