Rubyでハッシュ値の有無チェックをしてみよう

ハッシュ値の有無チェック has_key? を使ってみよう!

data = {:country => 'Japan', :town => 'Tokyo', :station => nil}

このデータがあるときに、countryがある場合に処理をしたいと言うときは

以下のような書き方をします。

if data.has_key?(:country)
    # お好みの処理を…
end

 

これで判定するケースは多そうなので便利ですねっ。

フリーランスがエージェントを使う時の注意点

便利なエージェントですが注意点があります

フリーランスを始めてエージェントを使うと案件も取りやすく

とても便利かと思います。

 

ただ、メリットもあればデメリットもある。

ということで私が個人的に感じたデメリットを書いていきます。

マージンが取られる

仕事をするにあたって毎月マージンを取られる会社が多いです。

営業会社を通さず自分で取引先を探すことができれば同じ仕事でも数万は高く

収入が増えると思います。

 

フォローします。など謳っている企業もありますが

正直いろいろ伝えても現場にいないエージェントは何かできるというケースは少ないです…。

 

結局自分の力に任されるという感じになります。

 

営業活動の時間がとりづらい

エージェントを通すと以下のような案件が多い傾向があります。

  • 客先常駐
  • 週5日
  • 客先に合わせた定時間勤務(8時間)

このような案件が多く、もし客先常駐をやめて他の会社と仕事をしたいということになっても

他社への営業活動の時間や交流など機会が取りづらいです。

 

私の場合、基本的に8時間フルで働くとヘトヘトで余力が残っていませんでした。笑

体力に自身がある方は違うかもしれませんね。

 

次の仕事につながる話が少ない

私の周りのエージェントを通して客先常駐をしているフリーランスは、

営業会社にマージンを抜かれてでも働きたいという人が多く

私と方向性が合わず次の仕事や人脈につながるケースは少なかったです。

 

どんなときにエージェントを使えばいいの?

こんなデメリットがあると、じゃあ、エージェントのよさってなんなの?

と思うと思いますが仕事が決まるスピード感は早いと思います!

 

突然、取引先の契約が切れたとしてもエージェントは案件を沢山あるので

早く仕事が決まりやすいです。

 

いざ困ったときに使うのがいいのかなとフリーランスを初めて3年経ち感じています。

 

何よりも時間に縛られたり、無駄なマージンが取られたり

フリーランスになったのに会社員と同じような縛りができるので

できるだけ早く個別の契約に移れるよう営業の時間を取れる余力を作ることをおすすめです。

RubyonRails実行時に突然javascriptエラーで動かなくなったときの対処法[Mac版]

Ruby on Railsでさっきまで動いていたのに突然javascriptエラー?

MacでRuby on Railsを実装時、gitのbranchを切り替える際など

いきなりjavascriptのエラーで動かなくなることが頻発していた。

 

コマンドを実行しよう

assetsの関係でつじつまが合わなくなっていた可能性があるのか

以下コマンドを使うことで解消した。

rake assets:clean
rake assets:precompile
rails s

 

もし、何か動かなくなったときは上記コマンドを試してみてください(*^^*)

Ruby配列の初期化に関する注意点

Ruby配列の初期化の注意点

Rubyの初期化をする際の以下の2つの方法の違いについて。

# 配列初期化 1
a = Array.new(3, 'TEST')
# => ["TEST","TEST","TEST",]

# 配列初期化 2 
a = Array.new(3) {'TEST'}
# => ["TEST","TEST","TEST",]

 

同じもののように見えますよね!

これが注意点。

 

同じ初期化結果なのに処理後、結果が変わってくる

配列の先頭を取得して置き換えてみましょう。

# 配列初期化 1
a = Array.new(3, 'TEST')
word = a[0]
word.downcase!
# word => 'test'
# a => ["test","test","test",]

# 配列初期化 2 
a = Array.new(3) {'TEST'}
word = a[0]
word.downcase!
# word => 'test'
# => ["test","TEST","TEST",]

上記、1,2で初期化の方法により代入後の結果が変わってきます。

 

同じように見えますが後々の結果に影響してくる初期化。

注意が必要ですね。

 

もし、参考になれば幸いです。

Ruby on Railsで動いているSlimを触ってみる

Slimとは?

HTMLで書く<div></div>などを簡易的に書いたテンプレート言語。

高速で軽量。

 

PHPで普通のHTMLを使ってきた私にとっては衝撃すぎました。

何これ…?という感じですw

 

簡単にメモ書きをしておきます。

HTMLの場合

<html>
    <head>
    </head>
</html>

Slimの場合

html
    head

 

え???という感じです。

 

Slimの特徴(HTMLとの違い)

  1. 通常のHTMLから <, >, /> を取り除く
  2. doctypeで書く
  3. テキストと | (パイプ)は改行するときに使う
  4. コメントの書き方は/もしくは/!で書く

1が一番の衝撃ですね。

でもこの書き方だけでも覚えておくとぱっと何かのときに出てきても

Slimだね!って適応できるかと思います。

 

私はSlimを知らなかったので衝撃すぎたのですが

Slimを知らなくてこの記事を見た方は次何かあっても対応の糸口がすぐ見つかるかもしれません。笑

 

日々、少しでも楽しみながら前進前進!

新しいことが知れて楽しかったので記事を書きました。

 

もし、何かの参考になれば幸いです。

トラブル案件を招かない見積もり方法

なぜいつもトラブル案件に遭遇するのか

プログラマの仕事をしていると残業が当たり前みたいな風潮があります。

会社員の頃は残業代も出るし、残業代がないと生活が苦しかったので

喜んで残業をしていました。

 

しかし、トラブル案件(炎上案件)で過労状態の時に体を壊し

それから回復するまでに非常に時間がかかりその間金銭面で苦しんだ経験から

トラブル案件の原因を考えるようになりました。

 

ときや場合によって、いろいろケースはあると思いますが

いくつかのプロジェクトを見ていく中で見えてきたものが1つあります。

 

トラブル案件になる大きな1つの原因

私がいくつかトラブル案件を見てきた中で共通していたのが「見積もりミス」です。

 

「見積もり」とは。

私の中の定義ではありますが、中の実装が固まってから正式に出すものだと思っています。

 

場合によっては、大枠だけ決めて概算見積として出すケースもありますが

あくまで仮で正式版ではないので、後日正式な見積もりを出す必要があります。

 

そして、大体のケースで見積もりが甘い、もしくは、締切が先に決まっているケースが多いです。

 

仕事量に対して、スケジュールを決めるべきものなのですが

上からの圧力なのか締切日が何故か先に決まっているのです。

 

普通に考えておかしな手順です。

 

どれだけ概算で見積もりを出してもいいのですが

最後はしっかりコードの内容を把握したり、把握ができない場合はそのリスクを提示して

スケジュールを出すべきだと思っています。

 

意外といる要注意な考え方の人

たまにいるのですが、見積もりはざっくりでやるもんだよ。

と、見積もりを諦めてる人がいます。

 

そして、ざっくりした見積もりで「できます」と言ってしまうんですよね。

 

おそらくその人の経験からの結論なので、否定することはできませんが

私は賛同できません…。

 

ざっくりでもいいと思います。

ただ、その上でのリスクをしっかり提示するべきですね。

 

何よりも大事なことは…

見積もりをする上で何よりも大事なことは素直に見積もること。

一緒に仕事をする人に対して素直に伝えることだと思います。

 

変に格好を付けて過剰な見積もりをすると後々の

つじつま合わせに苦労して作業にも集中できなくなります。

 

どれだけ格好をつけて良い見積もりを作っても

自分の実力がいきなり上がるわけではありません。

(たまに追い込んで無理して達成感を味わう人もいますがおすすめはしません)

 

正直に、伝えることができる相手と仕事をしましょう。

 

とても勇気がいることですが、自分の力を認めてできるものはできる。

できないものはできないとはっきりと伝えましょう。

 

それで、圧力をかけてくるなら…。

自分が潰れるのだけは避ける選択肢を選びましょう。

 

自分の体が資本です!

元気なメンタルと健康があってからなので、自分を大事にお仕事していきましょう(*^^*)

 

以上、私の炎上体験談でした。

何か参考になれば幸いです。

フリーランスが営業会社を使うメリット・デメリット

フリーランスの仕事探しで営業会社を使ってみる

フリーランスを始めたばかりの方は営業会社を通して

仕事を始める方も多いと思います。

私もその一人で、大阪から東京に来てフリーランスになったので

つてもなかったため営業会社と契約をして仕事をはじめました。

 

その際に感じたメリットとデメリットをまとめたいと思います。

 

今回、言っている営業会社とは東京で言うと

レバレジーズやギークス、クラウドワークスなどが有名所かと思います。

営業会社を使うメリット

  1.  希望した仕事・場所・単価の案件が比較的早く見つかる。

 

取引先が1社の場合やいきなり契約解除となった場合、

生活安定のためにすぐに仕事を探すことが出来ます。

営業会やを使うデメリット

営業マージンが引かれる

毎月営業マージンが引かれ入金されます。

私が使用したところはいくら毎月引かれているか不明なままでした。

しっかりとサポートしてくれる営業会社だといいのですが

客先常駐して取引先に入れて放置という感じも多いため

あまりいい気分で仕事ができない場合もあります。

客先常駐の案件が多い

基本的に客先常駐の案件が多いです。

リモート希望でもあまりいい顔をされず、客先常駐になってしまうことが多いです。

家で仕事をしたくない人や寂しいから誰かといたいという人にはメリットかもしれませんね。

ただ、私の場合は会議やセキュリティーの問題で客先でやる仕事があるなら客先常駐でもいいと思うのですが

1人で仕事をゆっくりとしたり不必要に満員電車には乗りたくないと思っていたので

フルタイム客先常駐というのはデメリットだったかなと感じています。

単価交渉がやりづらい

客先常駐先での単価交渉などなどの交渉がやりづらいのがデメリットかと思います。

話をするにも、私→営業会社→客先というように話が流れるので

また聞きで話が進み意図していないように伝わってしまう可能性も出てきます。

また、なぜか1年以上働かないと単価交渉してもらえないケースが多かったですね。

そういう面でデメリットを感じました。

 

さらに、初めての現場だからと単価を妥協した自分も悪かったなと感じています。

 

フリーランスを初めて単価交渉する際は

妥協せず欲しい単価を率直に伝えたほうがいいとつくづく感じましたね。

なので、これを読んでくださったフリーランスの方は自分の意思は曲げずに

単価交渉をしてほしいと思います。

 

結論

仕事、お金がないと生活が出来ないので

人脈がない場合は営業会社を使うことをおすすめします。

ただ、マージンなどいくら引かれているか不透明な中、

仕事を進めるのは不安なので平行して営業活動もどんどん進めていったほうがいいです。

 

以上、フリーランスになり営業会社を使っての感想でした。

参考になれば幸いです。

RubyもRailsも未経験が勉強を始めるときのコツ

RubyもRailsも初めて勉強を始めてぶち当たる壁

私は今まではPHPをメインに使っておりRubyは扱ったことがありませんでした。

いきなりRuby on Railsの本を読み始めていたのですが

Railsの仕組みを説明されてもRubyの書き方がまず理解できていないので

わけがわかりませんでした。笑

 

どれがメソッドで、どれが変数なの…?!状態です。

 

まず勉強するべきはRuby

まず初めは完璧でなくていいのでRubyのメソッドや変数の扱い方。

配列やハッシュの書き方くらいを勉強していくと良いと思います。

 

大枠がつかめて、こんな雰囲気なんだね。というのをまず掴みましょう。

 

私は、まずドットインストールでRubyの概要を理解して

Rubyの本へ移行しました。

 

大枠がわかった段階で次のステップへ。

Ruby on Railsのチュートリアルを始める

Ruby on Railsを勉強するときに入門サイトやいろいろ探して

勉強をしていたのですが、

いろいろ時間が経過した後、Railsのチュートリアル

ここから始めるのが一番すんなりと頭に入ってきました。

 

結構丁寧に書かれているんですよね。

部分的に書かれているブログとかをあさるより、まずここから始めることをおすすめします。

 

私の場合、他のブログやサイトを見ていたので

結構時間ロスをしてしまって後悔をしています。

 

RubyもRailsも大枠がわかったら交互に勉強と実践

RubyもRailsもおおまかな流れがつかめたら

更にRubyもRailsも深く理解をしてくために勉強と実践を進めていくのがいいですね。

 

一気に理解はできないかもしれないですが

少しずつ1日1つでも良いので前進してきましょう!

プログラマであるために技術力より大切なこと

プログラマは技術力が一番大事は本当か

プログラマの仕事をしていて

周りの人は技術の勉強を一生懸命しています。

 

プログラマの仕事として技術力はベースとなる重要なポイントになると思います。

が、それだけでしょうか。

 

私が思う技術力より大切な1つのこと

私が一番大切に思っているものはホウレンソウです。

 

若い人が多いチームだったりするとありがちなのですが、

技術に目がくらんで全然違う方向の仕事をしていたり

チームの方向と違う仕事を率先してやっていたり…。

 

それによって仕事全体のスピードが下がってしまったりすることがたまにあります。

 

 

また、ホウレンソウで周りと連携を取っていないために

「あの人はいつも何しているんだろう」と不信感に思われ

個人の信用も下がってしまいます。

 

本当のことを報告するのが怖い…。というときもあるかもしれませんが

嘘を報告は逆に信用を下げてしまうのでNGです。

本当のことを伝えて周りと策を練っていきましょう。

 

みんなと笑顔で仕事をしていくために効率的に仕事をしていくために

ホウレンソウをどんどん取り入れて行きましょう。

 

チャットやメールで短文でもいいと思います。

こまめな報告・連絡・相談で効率的に楽しく笑顔で仕事ができる環境を作っていきましょう。

PHP7ではてな(クエスチョン)2つってどういう意味?

PHP7から出てきた[はてな2つ]の意味

2015/12/03にリリースされたPHP7から出現したはてな2つなのですが、

nullのチェックができうようになりました。

例として、以下のような文を使うときに使えます。

// PHP7以前の場合
$test = isset($sample['a'])) ? $sample['a'] : 'no sample a';

PHP7になると以下のとおり。

// php7以降
$test = $sample['a'] ?? 'no sample a';

とても簡潔に書くことが出来ます。

if文の中でも使えますね。

$sample['a'] = 111;
if ($sample['a'] ?? '') {
    echo $sample['a'];
}
// 111が表示される

if ($sample['b'] ?? '') {
    echo 'test';
}
// なにも表示されない

$sample['a'] = 0;
if ($sample['a'] ?? '') {
    echo $sample['a'];
}
// なにも表示されない

こんな感じでシンプルに書くことができます。

ぜひ参考にしてみてください。