何もない空虚

動画を作っていたりいなかったり

スポンサーサイト 

上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。
trackback: -- | コメント: -- | edit

カネカネカネ 

ネットを介してお金を払う行為について、抵抗がある人は少なくないと思う。

例えばAmazonを使って何か買った場合、お金を支払う方法は、以下の3種類がありまして。

・コンビニ・ATM・ネットバンキング・電子マネー払い
・代金引換
・クレジットカード

で、自分としては、

・コンビニ・ATM・ネットバンキング・電子マネー払い ←めんどくさい
・代金引換 ←めんどくさい
・クレジットカード ←めんどくさくない

という感じなんだけど、共感してくれる人がいると信じて話を続けます。

数年前から、日本における、ネットを介しての売買を簡単に行えるサービステンプレートを作りたいなーとずっと考えていたりします。

ようするに販売サイトが作れるサービスを作って、配布して、そのサービスを買収されたら成功、みたいな。

ちょっと専門的な話になるけれど、それを作るにあたって、以下のポイントがずっと懸念事項としてある。

1. バックエンドを介したくない、サーバーにファイルを置いて完成!くらいにしたい
2. お金を支払うシステムはどうするのさ

1.についてはちょっとややこしいんだけど、ようするにサーバーにhtmlファイルを置いてはい完成、という感じで作っちゃうと、メールが送れないのだ。

これは未だに考えていて、回避できなくもないんだけど、うーん…といった感じになってます。

実際リニューアルした自分のサイトからは、バックエンドを通さずメールが送れるようになってます。

で、それ以上にやっかいなのが2.で、やっぱりお金が絡むとめんどくさい。

んで、色々自分なりに考えてきたけど、やっぱり一番抵抗感が薄くて利用率が上がりそうなのは、Amazonギフト券なのかなぁと。

写真素材とかを無料配布してるぱくたそは、どうやって収益を上げてるのかというと、

・Amazonギフト券による寄付
・PayPalによる寄付
・bitcoinによる寄付
・広告代

がメインなのかなと。

で、寄付については、ほとんどAmazonギフト券によるものがほとんどなんじゃないかなと勝手に思っています。

多分PayPalは外国人向けなのかな思っていて、となると、Amazonギフト券を介してやりとりするのが無難なのかなーと。

実際、自分のもし仮にAmazonギフト券でやりとりするとなると、抵抗感は薄くて、PayPalとかbitcoinとかだと、めんどくせぇなぁと思う気がするんですよね。

なので、もし実際にフロントのみで開発しようと思ったら、Amazonギフト券を介した感じで作ってみると、面白くなりそうだなぁと思った、今日この頃です。
スポンサーサイト
trackback: -- | コメント: -- | edit

さくら かふんしょう 

4月2日ということで、新年度ですね。

新卒社会人にとっては、いよいよながーい社会人生活が始まると思います、憂鬱な方も多いのではないでしょうか。

自分も気づけば社会人6年目のシーズンが始まるということで、大学を卒業してもう5年経ったのかと、アラサーですよ、アラサー。

今年も一年、平穏な日々を過ごしていきたい限りです。



平穏な日々を願いつつな今日この頃ですが、来月から職場が変わります。

今の現場とは今月4月いっぱいで終わることにしました。

先週商談を2つこなしてきまして、どちらも本当にとても魅力的な会社でした。

で、少し悩んだんですが、あとで受けた会社の役員さんから「他社さんが提示している額プラス1万円は払います!」とまで言われてしまったので、『男なら断るわけにはいくまい!』と思い、結果的に金で選びました。

まぁ、合わなかったら辞めるだけなので、まだ若いし…。(ゲスの極み)

恐らく今月末に退職エントリを書くと思います、色々と思うところがあり、ちょっと激しめの内容になりそうな予感です。



上に書いた通り、先週面接を受けてきました。

人生で何度か面接を受けてきましたが、最近少し、面接での受け答えのちょっとしたコツを掴んできた気がします。

『このワードを使ったら心象が良くなるなぁ』というのが具体的にいくつか見つかってきたので、技術ブログの方に近々まとめようと思います。



給与的には順調に上がっていっているのですが、その一方で、プライベートはなかなかどうして…といった感じです。

うまくいくこともあれば、うまくいかないことももちろんあって、28の自分を振り返った時に、自分もまだまだ子供だなぁと。

このブログを書き始めたときからずーーーーーーーーーっと書いていますが、やっぱり友達がいないのが良くないよなぁと。

仕事を頑張ってきて、技術力もコミュニケーション能力も上がりつつあるのは、多少なりとも感触としてあるのですが、その一方で自分の人間性って、実はほとんど上がっていない、それどころか下がりつつあるのでは…?と。

その証拠が周りの人間関係であって、もちろん自分があまりアクティブに交友関係を広げようとしていないのもあるとは思うのですが、それにしたってここまで変化がない状態に、正直予想外でした。

でもまぁ、友達って急いで作るものでもないですし、自分の運命はそんなものなのかなーと思うようにもなってきました。

けせらせら、なるようになりますかね。
trackback: -- | コメント: -- | edit

認めること、認めないこと 

プログラマとして働き始めて、あと1ヶ月で5年目が終わります。

長いとも短いとも言えない5年間でしたが、様々な現場で働かせてもらい、たくさんの方と共に仕事をしてきました。

で、プログラマとして一緒に働く仲間は、どういった能力を持っている人だと互いに働きやすいのかということを、ふと考えまして。

コミュニケーション能力に長けているとか、ロジカルシンキングができるとか、単純に明るいとか、いろいろとあるっちゃあるんですよね。



そんな中で、個人的には、整理整頓に対する美的感覚を持っているというのは、とても大事だよなーと思っています。



プログラミング未経験の人って、プログラミングは未知のものであって、とても難しいものだという印象を持たれている方がとても多いと感じます。

自分も大学を卒業するまでは一切プログラミングに触れてきませんでしたし、『プログラミングって難しいんだろうなー』と何となく考えていました。

そこから社会人になって、始めてプログラミングに触れて、5年が経ちました。

今あらためてプログラミングに向き合ってみると、プログラミングが難しいという考え方は、本当に単なる幻想でしかなくて、小学生でも数分学べばすぐにでも書けるものかなーと。



ただその反面、他人から認められるプログラミング、仕事で通用するプログラミングというのは、本当に難しいです。



例えば、以下に2つの文章があるとします。

A. にわにはにわにわとりがいます。

B. 庭には2羽、にわとりがいます。

AとBどちらの文章が読みやすいでしょうか。



個人的にはBの方が読みやすいです。

ここで、どちらが読みやすいと判断できるか、なぜ読みやすいと思ったのか、もしAの文章のみが提示された場合、Bのように書き換えることができるか。

これが、整理整頓に対する美的感覚を持っているかどうか、ということです。

先の例で言うと、もし仮に上司に上記の文章を送る必要があった場合、Aを書く人はほとんどいないと思います。

でももし、例えば自分のプライベートなブログに書く場合であれば、Bのように書く人が多いかもしれませんが、人によってはAのような記述を行う人も少なからずいると思います。



結局プログラミングにも同じことがいえて、



・プロジェクトでコーディング規約は定められているか、またコーディング規約に沿ってコーディングを行っているか

・プログラムに感情を入れ込んでいないか、気分が良くて自分本意なコードになっていないか、気分が荒立っていて自分本意なコードになっていないか

・他人が読んで理解できるコードになっているか、自分以外が理解できないプログラムでは仕事で通用しない

・本屋の本がジャンル別、作者名順に並べられているように、プログラムやソースファイル、プロジェクトに関わる全ての単位において、整理整頓が行われているか



上記諸々含め、全て整理整頓に対する美的感覚を持っていれば、解決されると思っています。

そんな感覚を持った仲間と一緒に仕事ができれば、高いレベルで互いに高めあっていけるのかなーと。


-- 続きを読む --
trackback: -- | コメント: -- | edit

あいさつができる人、できない人 

今の現場で学んだことの一つに、あいさつができる人はとても印象が良いということです。

しごく当たり前のことなんですが、それでも改めてその事実を再認識した次第です。

というのも、今の現場の社長、一切あいさつができない、まぁ言ってしまえば情けない人だなぁと思っていまして。

ところが最近、とある事情から外部の会社の人が現場に常駐するようになっていまして。

その人たちのあいさつの気持ちの良いこと、すばらしい。

もうそのあいさつだけで『あ、この人の印象いいなぁ』と思ってしまう自分がいました。

自分もそこそこあいさつはする方なんですが、あいさつに対してあいさつを返してくれない人にはムッとさせられることも少なくありませんでした。

それに対して、外部の会社の人というのもあるかもしれませんが、そんな小さなことなんてどうでも良くなるようなあいさつ!

すっかり自分の小ささに、反省しきりです。

そもそも、あいさつって、行うだけでメリットが得られる便利なモノだよなーと常に思っています。

お金もかからないし時間もかからない、こんなすばらしい行動すらもできない社長って…と考えると、メリットデメリットも考えることもできない社長の下で働く自分はどうなのか?と思わざるをえないですね。

これからはリターンがどうこう相手がどうこう、そんな小さなことを考えず、自発的にはっきりしっかりあいさつをしていこうと思った今日この頃です。
trackback: -- | コメント: -- | edit

後ろへ前へ 

今の現場からそろそろ離れようかと少しずつ考え始めました。

毎度のことながら理由は大小様々あるのですが、そんな理由の一つに「作っているものと、それに対する労力が見合っていない」というのがあります。

自分は今フロントエンドエンジニアとして働いています。

職務内容を簡単に言うなら、Webブラウザで表示される画面を作っている、という感じです。

で、自分が携わっているチームで作っているのが、自社向けの小さなWebサービスです。

んで、決して規模が大きいとは言えない、しかも社内向けのサービスにも関わらず、上司からやたら細かい作業指示が来ている状態でして。

自分としては、そこにひじょーに不満を持っています。

今現在、自分たちが作っているサービスの改修リリースを行う際に踏まなければ行けない手順は以下のようになっています。

1. 社員との仕様確認
2. バックエンドエンジニアとの仕様確認
3. プログラム開発
4. チーム全員によるプログラムレビュー
5. 単体テスト
6. 結合テスト
7. 総合テスト
8. リリース!

特におかしな手順があるわけではないですし、手順の流れに対して不満は一切ありません。

ただ、上にも書いた通り、各手順に対する労力が大きすぎる!!というのがひじょーに不満なのです。(2度目)

特に個人的に不必要だよなーと思うのが、4のチーム全員によるプログラムレビューです。

プログラムレビュー自体はとても大切なことですし、各メンバーの実力を上げるための絶好の機会だと思います。

とはいえ、レビューを行う以上は、しっかりとしたコーディング規約を制定すること、そのプロジェクトにおけるルールを明文化することがとても大切だと個人的には思っています。

明確なルールが決まっていない状態で、各人がプログラミングを行い、各人がレビューを行ってしまっては、何が正解なのかわからない上、毎回行き当たりばったりな意見が浮上し、結果的に上司の脳内にのみ存在する、個人的なルールに押し付けられるという事態に陥りかねません。
# プログラムレビューについては、以下の記事がとても良かったです。
# これからは自分もこのテクニックに則ってレビューをしていこうかなーと。
# 人間らしくコードレビューするには

と、ここまで書けばわかると思いますが、すでにそういった状態になっているので、すごーく嫌だなーと思う日々が続いています。

特に象徴的だったのが、上司が以前書いていた既存のコードを、コピーして貼り付けてそのままリクエストを送ったところ、他のメンバーから「この書き方はよくない」と指摘されたことがあり、結果的に自分の書き方が良くなかったと思われる事態がありました。

また、単体テスト・結合テストについても、テスト自体はとても大切なことだとは思うのですが、『社内向けの小さなサービスに、山ほど時間をかけてまで、そんなにしっかりテストする必要なんてあるのか…?』という疑問は常に晴れません。

加えて、テストの観点について何度か尋ねたところ、「まかせるから」の一点張り。

何をテストしたいのかわからないし、そもそも何を目的でテストをするのか、恐らく上司自体も『テストは大切だけどめんどくさいし、よくわからないから派遣に全てまかせよう』という考えなのかなーと。

で、もし自分が上司だったら、以下のような手順で進めさせるのかなーと。

1. 社員との仕様確認
2. バックエンドエンジニアとの仕様確認
3. プログラム開発
4. リーダーによるプログラムレビュー
5. 総合テスト
6. リリース!

まず真っ先に、単体・結合テストを取っ払います。

何度も書いている通り、テスト自体はとても大切なことです。

が、しょせん社内向けの小さなWebサービス。

どちらかといえば『バグが出たらその都度直せば良いでしょ』くらいの軽い気概でいても良いと思っていますし、むしろそこにかける時間と労力がもったいないです。

もちろん言わずもがなですが、これが世間の目に触れる大規模サービスでしたら話は全く違います、ケースバイケースといってしまえばそこまでではないでしょうか。

で、次にレビューの度合いも下げます、少なくともフロントエンドエンジニア全員でやるような規模じゃないです。

加えて、コーディング規約も存在せず、プロジェクト内のルールも明文化されていない以上、上司の脳内ルールに従う他ないのですから、ならばいっその事上司だけがレビューすれば良い、個人的にはそう思います。

これくらいシンプルにことを進めて、さっさと次のことを始める、それくらいはしないと、時間ばかり食って、その割に労力に見合わないモノが出来上がるだけです。

時代と逆行していると感じざるを得ないこの状況、もうしばし進退について、考えてみようと思います。
trackback: -- | コメント: -- | edit

上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。