「Gem」を含む日記 RSS

はてなキーワード: Gemとは

2019-06-16

anond:20190616180156

いや事実ぎゃあぎゃあ騒ぐことが目的でしょ?

よくするならGEMなりGDIなりGIIなりしってるやろ普通

anond:20190616180156

https://dictionary.goo.ne.jp/jn/246301/meaning/m0u/

人間開発における男女間の格差を示す指標国連開発計画(UNDP)が、以前のジェンダー開発指数GDI)およびジェンダーエンパワーメント指数GEM)に代わるものとして、2010年から発表。妊産婦死亡率や女性議員比率などをもとに算出される。日本は188か国中17位(2016年版)。男女不平等指数GIIGender Inequality Index)。

[補説]男女間の格差を国別に示す指標としては他に、世界経済フォーラム(WEF)が発表するジェンダーギャップ指数(GGGI)がある。

逆に聞くが、WEFのGGGIだけが信頼できる根拠は何?

2019-04-21

年功序列構成からNASAGEM boxのように変わるのか

NASA年功序列組織運営をしていたところから組織を変えたことがある。

望ましいと思える人を適切に配置するのが目的だ。それがGEM boxという組織図で表されてる。

https://en.wikipedia.org/wiki/File:GEM_box_organization_chart.jpg


アポロ計画活躍した、女性プログラマーマーガレット・ハミルトンにつながる。20代~30代の話だ。


人種性別、年齢を超えて、プロジェクト推進に適任者を充てる組織日本が作れるのか。

2018-10-01

合成やガチャのない地味なスマホゲー書いてみる

anond:20180928003107

Gem Miner

ドワーフ鉱石を掘っていく横2Dパズルアクション鉱石掘って持ち帰ってお金に変えてアイテムを買って、さらに深く潜っていく。敵は出てこず、落石や落下やエネルギー不足で死亡。途中まで遊べる無料版のGem Minerと、買い切り版のGem Miner: Dig Deeperがある。ドワーフアイテムハシゴを消費しないと上には登れないので、どう掘っていくかをよく考える必要がある。マップランダムなので何度でも遊べる。

Jewels Legend

6角形のマス目で、同じ色の石をなぞって消していくパズルゲー。アイテムとかキャラとか一切なくストイックに石を消していく。時間制限があり、瞬間の判断で次々に石を消していく必要があり、好成績を狙うには何気に集中力と瞬発力を要求される。無料だがちょっと広告がうざい。

Dungeon Cards

3×3のシンプルなマス内で、アイテムを拾ったり敵を倒したりしていくパズル要素のあるRPG武器を持っていれば武器を消費してノーダメージで敵を攻撃できるが、武器がないと体力を削って攻撃することになる。体力より多い敵に突っ込んだら死亡。他にも宝箱や罠や爆弾などいろいろ出てくる。クリア時にお金をもらって初期ステータスを強化していく。広告を見るとクリア時のお金が倍になるという優しい設計

マグネットボールパズルゲーム

いわゆるパズルボブルだが、バブルではなく磁石の玉っぽいのを投げるので、動きが磁石っぽい。キャラアイテムも出てこないが、玉の動きがけっこう新鮮で、地味にハマる。

マモノスイーパー

マインスイーパー+RPG。マスにレベル1~10魔物が潜んでいて、自分レベルより弱いヤツなら無傷、強いやつならレベル差分ダメージを受ける。開いたマスには、周囲の敵のレベルの合計値が表示されるので、その値から敵のレベルを推測してマスを開いていく。敵を倒すことでレベルが上がり、より強い敵を倒せるようになる。けっこう頭を使う。

ブロッサムブラスト

なぞり系パズルゲーム。同じ色の花をなぞって集めると大きくなり、一定以上の大きさで弾けて、周囲の花も大きくする。単に消せばクリア、というわけではなく、面ごとにクリア条件が異なり、一気に消すべきか徐々に消すべきかを考える必要もある。演出が派手。失敗するまではライフが減らないので、クリアし続ければ永遠に遊べる。キャンディークラッシュ会社

Sudoku Plus

いわゆる数独。9×9マスの枠内に縦横3×3マス内で数字が被らないように配置していく。味も素っ気もないが時間つぶしにはもってこい。本物は難易度4つ×1000問が広告もなく遊べるが、広告が入ったり問題が少なかったりする類似コピー品が出回りすぎてもはや本物がどれかわからない。

セルコネクト

6角形のマスに2の倍数の数字が入っていて、同じ数字を4つ集めるとその数字の4倍の値になる。マスをいっぱいにしないようにしながら、同じ数値を集めて値を大きくしていく。キャラも何もないシンプル数字パズルだが、ハマると終わらなくなる。ただある程度コツがわかってしまうと、永遠に終わらない地獄が待っている。

かにもこういうゲーム知ってる人いたら教えてください。

2018-04-07

仮想通貨未来を左右するのは決済支援ライブラリの充実度だ

言っちゃ悪いがBitcoinは、お世辞にも通貨とは言えない。

通貨と言うからには物々交換代替できなければならないのだが、Bitcoinは明らかに物々交換代替できていない。

日本国内にお店は無数にあるのに、Bitcoinで決済できるお店は皆無に等しい。

何故か。

1. BitcoinPoWで、破綻自明からBitcoinを取り扱ってくれないのか?

2. Bitcoin価格不安定からBitcoinを取り扱ってくれないのか?

理由としてそれっぽく聞こえるが、一番の障壁はいずれでもない。

最大の理由は決済支援ライブラリの欠如だ。

お店が既にRailsベースインターネット通販の仕組みを運営していても、そこにBitcoin決済の機能を足すのが難しすぎる。

これは、よくよく考えれば不思議な話である

Railsなら、たいがいの機能gem installできる。例えば、明らかに面倒なユーザ管理機能もdeviseで一発導入できる。

しかBitcoin決済の仕組みはgem installで導入できないのだ。

明らかに需要があるのに、何故、誰も作ろうとしないのだろうか。

もしかして技術的に大変困難、もしくは不可能なのか?

決済ライブラリを作るのが不可能ということは、Bitcoin永遠に通貨になれないということか?

2018-03-29

ツール系の準備に ruby 必要なのはやめてほしい

ネットで見かけて使ってみようと思ったものの、インストール手順を見ると ruby やら gem やらインストールして、と書いてるものが少なからずある

それをみるととりあえず、このツールはいいや、と諦める


わざわざ入れたくないし

pythonperl ならデフォルトで入ってるし選択肢としては問題ない


ruby 自体に関わるものならともかく全く ruby関係ないのに必要とかやめてほしい

なぜ ruby にするのか

私のようにそれだけで敬遠する人は少なく無い

多くの人に使ってほしくて作ってるのだとしたら選択を間違ってる

2017-10-05

anond:20171005124057

追記。redmineだけwww-dataユーザーで手動展開してwww-dataとして必要gemredmineディレクトリ内に(必要なdevをaptで入れて)インストールしたら動いた。

やっぱりあちこちディレクトリ分散させたredminedebが俺には繊細過ぎたのだ(rubyrailsnginxとphusionpassengerはdebのまま)。作業ディレクトリいっこ万歳

2017-09-06

コードが書けない焦燥感

Railsアプリを作るとき、便利なgemが多すぎて自分ガッツリコードを書くことがめっきり減った。

スピード感という観点からは好ましいことかもしれない。

しかし、このままでは自らの技術力が成長しないのではないかという激しい焦燥感に襲われている。

仕事時間内で技術勉強も兼ねなければ、なかなか勉強時間が取れない。

だが仕事では、便利なgem検索簡単サンプルコードを書き、どれだけ楽に実装できるかの選定ばかりだ。

私は1年後に飢え死にしてはいないだろうか。毎日そればかりが気になって、精神不安定状態にある。

2017-08-26

Rails ってそんなにいいか・・・

Rails を使ってはや10年。

Rails のことはかなりわかっている方だと思う。

だが、最近 Django (Pythonウェブフレームワーク)を使いはじめて、いままで苦労して Rails を使ってきた努力は何だったのだろうと思った。

Rails だとすぐアプリが開発できると人はいう。

それは嘘じゃない・・・だが大きな犠牲を払ってだ。

RailsRuby の柔軟さを利用(悪用)して、徹底的に Ruby 言語が改変されている。

DSL が多用されている。

要するに、「レール」を外れると、どうしたらいいのかすぐわからなくなるのだ。

から四六時中、フレームワークプラグインgem)のソースコードを解読しようと格闘する羽目になる。

その点 DjangoPython らしく、フレームワークは余計なことをしない。こちらが何かしないかぎり、何も起こらない。

すべては明示的(explicit)に行う必要がある。

明示的なものは暗黙的(implicit)なものよりよい、というPython、そして Django思想

なんという安心感だろうか。

しかRails のほうが開発に必要記述量は少なくなるかもしれない。だけど、わずかな記述量を節約したところで、見通しが悪くなったら元も子もないではないか

私は、本当に Rails 教に洗脳されていたんだな、といま感じている。そして、洗脳から解放され、いま、より広くて成熟した Python コミュニティに参加しようとしている。Ruby も悪くない言語だし、Rails もよいフレームワークだけど、もういいかな。これからPython と共に歩もう。

2017-05-25

最強の思考停止センテンス~「Railsから」その1(…続くのかよ)

(Railsに限らないけど)DBスキーマだけでアプリ仕様表現できていないようなスキーマ設計やめてほしいんだけど。

「○○というrails向けのgem使うと勝手スキーマ設計してくれたうえでこういうことできるんだ」(スキーマだけでは表現できていない制約をrubyコードで実現するタイプgemみたい)

…それアクセスするのrailsだけじゃねーんだけどみたいな、てかそういう不誠実なgem公開してるやつプログラマーになる前に(贅沢いわないから)情報系の学校で直してほしいんだけど(って化学系の学校出身あほな僕につっこまれてるの恥じてほしいんだけど)

なんでDBだけでちゃんと仕様表現できないかな(じゃなくてそもそもしようとしないかな)?みんな大好きマイクロサービス考慮すれば(僕が今担っているアプリはそのマイクロサービスの部類)「Railsから」は成り立たないと思うんですが?…僕がおっさん過ぎて気にしすぎなのかな?…であれば僕も気にせず「いや、僕おっさんからそれ気にくわねーんだけど」と誠実に対抗するのが正しいのかな?

2017-05-02

マストドンAPI

マストドンリポジトリ

ttps://github.com/tootsuite/mastodon

マストドンAPIリファレンスAPI実装済みのライブラリ(サードティ)の紹介

ttps://github.com/tootsuite/documentation/blob/master/Using-the-API/API.md

マストドンAPIに関するドキュメントが置いてあるディレクトリ(色々ある)

ttps://github.com/tootsuite/documentation/tree/master/Using-the-API

マストドンアプリ認証にdoorkeeperを使ってるので認証APIはこっちを参照する必要がある

ttps://github.com/doorkeeper-gem/doorkeeper/wiki

マストドンドキュメントで紹介されてるAPI実装済みのライブラリ(サードティ)を使うのが一番ってっとり早い

以上

=====

わざわざ自前でAPIを叩くコードを書く

step1

アプリマストドンサーバー登録する

ttps://github.com/tootsuite/documentation/blob/master/Using-the-API/API.md#apps

POST /api/v1/apps

必要データをPOSTするだけ、難しくない

アプリ登録をわざわざコーディングする場合ライブラリとして作って提供する場合くらい(?)

(アプリ複数インスタンス対応させる場合はやはりコード書くしかないけど)

(登録したIDを自前サーバーで持って同一アプリで共有するとか?)

別にhtmlフォーム作って送信するだけでも登録できる

(ローカルhtmlファイル作ってブラウザ表示して必要入力してsubmit送信するだけ簡単)

<form name="regsterapp" method="POST" action="http://SERVERNAME/api/v1/apps">

<input name="client_name" type="text" value="">

<input name="redirect_uris" type="text" value="urn:ietf:wg:oauth:2.0:oob">

<input name="scopes" type="text" value="read write follow">

<input name="website" type="text" value="">

<input type="submit"></form>

step2

ユーザに対してのアプリ認証

doorkeeperについて知る必要がある

ttps://github.com/tootsuite/documentation/blob/master/Using-the-API/Testing-with-cURL.md

このページに書いてあるgrant_type=password認証法ではread権限しか貰えないぽい

grant_type=authorization_codeで認証する必要がある、これ読めば早い

ttps://github.com/doorkeeper-gem/doorkeeper/wiki/Authorization-Code-Flow

GET /oauth/authorize

必要パラメータ(※1)つけたリンクアプリ認証したいユーザに踏んでもらい許可を押してもらった上でそこで表示されるコード(RETURNED_CODE)を使う必要がある

(自前サーバーなどでリダイレクトで受け取ることもできるけど)

その表示されたコード(RETURNED_CODE)を使って次のAPIを叩くと認証完了する(アクセストークンをゲットできる)

POST /oauth/token

これもただのPOSTになるのでそんなに難しくない

さっきのアプリ登録みたいにhtmlとかで簡易にもできるけどアプリ秘密キーを使うので公開はダメでしょうな

※1

ttp://SEVERNAME/oauth/authorize?client_id=YOUR_CLIENT_ID&redirect_uri=urn:ietf:wg:oauth:2.0:oob&response_type=code&scope=read+write+follow

scopeというパラメータで取得したい権限指定する必要がある

step3

認証終わってアクセストークンをゲットしたらもうAPI使えるので

ttps://github.com/tootsuite/documentation/blob/master/Using-the-API/Testing-with-cURL.md

これの2番目に書いてあるようにHTTPのヘッダに Authorization: Bearer ACCESS_TOKEN を加えてから

APIの叩けばよい

toot(トゥート)はAPIドキュメントではstatusという表現になってる

ttps://github.com/tootsuite/documentation/blob/master/Using-the-API/API.md#statuses

POST /api/v1/statuses

がtootするためのAPI

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にしてくるやつらの態度が嫌なんだよ

2017-02-26

自動化って

暗黙知をなくす作業でもあるなぁと思った。

Ansibleとかはサーバー構築手順書をなくすことができるし、mavengemなどのパッケージ管理ツールセットアップ手順の暗黙知をなくすことができる(なんのライブラリ入れるーとか)

人にあれこれ聞くより、コード見て大体わかるような感じになっているとすごく助かるんだよなぁ。

もしかしてそういう感じで仕事を続けていけば、英語圏とかでも仕事できるようになるのかなぁ。

vagrant up ← コレだけで開発環境揃う環境、素敵に開発に入りやす

わしが1年1人でやっているやつ、ミドルウェア系には秘伝ミソが少し出来ているから、dockerで全部揃うようにしてみるかなぁ。Solr使っている部分とかしょうがないような気もしつつ、ローカルにあったほうが良いんだろうなぁ。あんま頻繁に開発しないし、そこは自分でやればいいか・・・。まあ多分solrコンテナを立てれば良いんだろう。

2017-02-01

ホワイトリスト形式プロキシ建てるのやめてほしい

大手SE会社作業することになったけどさあ・・・

mavenもnpmもpipもgemdocker hubもつながらないような環境で開発しろとか言われてもムリだよ

CentOS公式リポジトリだけ開けてれば問題ないとか思ってんじゃねーぞ

プロキシ建てるのはいいけど、リストメンテする気がないなら、せめてブラックリスト形式にしてくれよ。仕事できないよ

2016-09-12

民放TV局が邦画製作に参入したことによるあれこれ

http://anond.hatelabo.jp/20160912143056

  地上波TV局が国産映画製作に参入したことによる倫理的構造問題点

  調査会社GEMリサーチ等を分析レポートする。

【1 国産映画と輸入映画宣伝費用格差問題 】

 ○日本市場において、輸入映画認知度に対する動員の相関が国産映画より安定している。

 「邦洋別、認知度の相関」http://column.gempar...ploads/2013/02/1.gif

  http://column.gempartners.com/?p=5608

  >ここでみて明らかなとおり、邦画は、テレビCM番組露出も、出た分だけ興収に結びつくとは

  >限らないという状況にあることがわかります。一方の洋画は、露出量と興行収入がより相関しているのです。

 ○映画製作している地上波TV局にとって、自社以外の映画は競合相手であり、洋画はすべてそれにあたる。

  邦画同士の場合俳優事務所などの横のつながりで他社作品を紹介する可能性はあるが、他社作品用は枠はこれで消化される。

  地上波TV局は、少なくとも結果だけ見ても、洋画番組露出量を低下させている。

  最終興収60億の「レ・ミゼラブル」も番組露出は非常に少量であった。http://column.gempar...ploads/2013/02/3.gif

  ・邦画の自社の電波の強み ←→ 邦画と競合しているためCM枠を買うしかない洋画さらに、TV幹事邦画CM枠代自体がかからない)

  http://column.gempar...loads/2013/03/21.gif

  ・テレビ局別の映画宣伝量と自社出資作品割合

  http://column.gempartners.com/?p=5610

 ○その結果発生した、認知度と興行の変化

  ・メジャー洋画2010年と比べて2013年は平均認知度が13ポイント下がっている◆

  ・認知が低くとも高稼働の作品が増えてきている◆

  http://column.gempartners.com/?p=8994

  http://column.gempartners.com/?p=9069

 ☆何が問題

  地上波放送局は限られた電波を国から借りた免許事業であり、新規参入ができない非自由競争市場既得権益である

  そのため放送法によれば本来、局が出資している別業種製品宣伝違反行為である。  

 ★糾弾が広まりにくいのは?

  テレビ系列媒体新聞ラジオ)、TV依存媒体週刊誌など)は勿論この問題には言及しない。

  ネットメディアフリージャーナリストなどが散発的に指摘するも、マスでアジェンダ拡散されることは決してない。

2016-09-03

http://anond.hatelabo.jp/20160902031012

http://anond.hatelabo.jp/20160902031012

はてブ批判してる人たちよりよほど志のある学生さんだと思うので、いろいろ書いてみますおっさんのたわ言ではありますが、元記事の人にすこしでもヒントになればと思って。

大学に行っても実用的なソフトウェアを書けるようにはならない

実務の話!! 実際に「IT系のおしごと」というのがやってるような話で、特にコーディングに直接絡んでくるようなもの

技術実態みたいなやつ。そういうのは学校で教わらないんですよね。

まず、日本大学勉強しても実用的なソフトウェアが書けるようにはなりません。どういうことかというと、「情報系の大学に行けば○○が作れるようになる!」という世間一般の期待と、実際に大学で教えている内容には大きなギャップがあるということです。

これは大学が悪いのではなく、大学はそもそもそういうものであって、それが世間認知されてないというだけです。

具体的に挙げてみましょう。

大学で教えてる内容ってこんな感じなので、ゲームアプリサービスを作ることが目的の人から見ると、役に立たない内容にしか見えませんし、実際たいして役に立ちません。その証拠に、大学情報学科を出ていないのにゲームiOSアプリWebサービスを作っている人はゴマンといるし、逆に日本大学先生ゲームiOSアプリWebサービスを作れる人はほとんどいません。

日本大学先生実用的なアプリサービスを作った経験がない

これは重要ことなのでもう一度書きますが、日本大学先生ゲームアプリサービスを作れる人はほとんどいません。大学先生が得意なのはプログラムを書くことではなく論文を書くことです。論文のためにプログラムを書くことはありますが、あくまでおまけです。

そのため、大学勉強してもゲームアプリサービスが作れるようにはなりません。だって教えている側の先生が、ゲームアプリサービスを作ったこともなければ、作り方も知らないんだから

そういう経験のない人たちばかりですよ、日本大学先生って。そんな人たちの授業を受けて、アプリサービスが作れるようになると思うほうがおかしいでしょう。

ためしに、先生方のTwitterアカウント名でGithub検索してみてください。いまどきGithubアカウントがないとか、あったとしてもTestCaseすらないコードとか、そんなものばかりです。「研究内容をライバルに知られるわけにはいかないかGithubは使わない」という言い訳する人がいそう。けど、本当はGitが使えないだけでしょ?

あるいは、先生方の個人ページや研究室の紹介ページを開いて、HTMLソースを見てみてください。doctype宣言がないとか、viewportの指定がないとか、Pタグの中にULタグを使ってるとか、そんなのばかりです。HTMLすらろくに書けない人が、Webアプリを作れると思いますか?きっとXSSCSRFも知らないですよ。

ですので、そういうことを勉強したいなら、ベンチャーIT系企業に入るべきです。大学でそういうことを勉強しようとしても、教えられる人がいないから無理。
(「大学はそんなことを教える場所ではない!」と怒る人いると思うけど、教えられる先生がいないという事実ごまかすために怒ってるだけだから。)

ジャンルが違う

はいっても、大学先生プログラムがいっさい書けないというわけではないです。彼らが得意なのはコンパイラインタプリタOSやソルバを作ることです。これらも実用的なソフトウェアと言えなくはありませんが、ゲームアプリサービスとはジャンルが大きく違います

そのため、大学情報学科に進めばコンパイラOS機械学習ライブラリを書けるようにはなるかもしれませんが、それはゲームアプリサービスではないので、繰り返しになりますがそれらを作りたい人には大学は向きません。

大学で教えている内容ってムダなのか

じゃあ大学で授業を受けるのってムダなのかというと、必ずしもそうではないです。

大学で教えている内容って、ゲームiOSアプリWebサービスが一通り作れるようになってから、その先を目指すときになって初めて必要になることが多いです。たとえば、

こういうときになって、初めて大学で教わった内容が生きてきます。逆にいうと、そういう状況にならないと、大学で教わった内容は生きてこないと言えます。(情報系の学科で学んでいるなら、ライブラリ言語OSを「使う人」ではなく「作る人」にぜひともなってほしいですね。)

元増田に進めたい進路

元増田は、社会に役立つ実用的なソフトウェアを作りたいようです。しかし残念なことに、大学が教えている内容はその目的には合致していないことを説明しました。

こういう事情なので、元増田には大学ドロップアウトしてIT系会社入社することをお勧めします。ドロップアウトが難しいなら、インターンバイトでなんとしても入り込むことです。

入るべき会社は、教育に力を入れている会社です。20人未満の小さな会社では教育に力を入れている余裕はないので、小さな会社はやめたほうがいいです。簡単にぐぐってみたところ、はてなPixivクックパッドDeNAドワンゴ教育制度確立しているようです(違ってたらごめん)。そういった会社に入ったほうが、大学の授業を受けるよりも、元増田目的にかなうのは間違いありません。

そして何年か働いて、iOSアプリWebサービスが一通り作れるようになったら、大学に入り直すことです。これはとても効果的なので、元増田には強くお勧めします。

上で説明したように、大学というところは、ゲームアプリサービスの作り方は教えてくれず、それらが作れるようになって初めて役に立つことを教えてくれます。そのため、元増田IT系会社に入ってアプリサービスの作り方を勉強し、それらが作れるようになってから再度大学の門をたたくのが、いちばん効率的です。

なお繰り返しますが、入るべき会社は「教育に力を入れている会社」です。今のIT系企業では、インターン生を「格安で使えるバイト君」としか見なしていない会社が多すぎます。そういう会社は、コストが掛かることはいやがるので、教育もろくにはしてくれません。逆に教育に力を入れている会社では、インターン制度を「将来の戦力を選別する期間」と見なしています

残念ながら、そういう会社東京に集中しているようです。例外京都はてなくらいでしょうか。地方大学生にとってはつらい現実なので、はてなPixivドワンゴ地方でのインターン開催をお願いします。あとレベル5は九大と九工大学生を鍛えてあげてください。

余談ですが、学生さんにひとこと:

インターンバイトで潜り込む先の会社を選ぶときは、就活と同じような時間をかけて選んでください。バイトからとかインターンからという軽い気持ち会社を選ぶ大学生が多いから、それを食い物にしている悪質経営者があとを立ちません。インターン生が「格安学生バイト」として使われている現状を是正するために、学生のほうでも注意してください。

大学で授業を受けなくても独学で効率的勉強する方法

ドロップアウトを進めた手前、書こうと思ったけど、長すぎるのでやめた。

リツイートが100超えたら書く。

2016-06-20

全てのCOBOLエンジニアはだいたい糞である

この記事を読んだ。

http://anond.hatelabo.jp/20160619185731

COBOLエンジニア、現Rubyエンジニアとして増田記事がどうしても許せなかったので反応してみる。

この記事もこんなタイトルだけど、これもやっぱり主語が大きいと思う。

汎用系の現場でもRuby現場でも優秀な人はたくさんいたし。

今では信じられないほどの経験を当時(といっても2年前)はしていた。

改めて今、RubyというかRailsを始めてよかったなーと思う。

そこで僕が経験した糞だった現場をご紹介したい。

(もちろん業界特有ということもあると思うが)

インデントは定規で計る

いやー、これが一番ひどかったな。

まず静的デバッグ(机上デバッグ)といってコンペアファイルソースコードコンパイルログをそれぞれ紙出しして提出用(クライアント)、リーダー上司用の3部印刷する。

全てマーカーを塗った後に赤入れする為にそれぞれ分けるんだ。

1セットあたり印刷に15分くらいかかったかな。

そしてインデントレビュー指摘項目なんだけど、紙出しされたもののインデントが正しいかチェックするんだよ。

媒体のインデントをどうチェックするかって?

定規で計るんだよ。半角スペースが5ミリだったっけな。

それで5ミリずれてたら指摘するんだよ。目がつかれたよね。

っていうか品質に対する意識は今のほうがよっぽど高いし効率的だよ。

ログを紙出ししてマーカー塗る専属社員がいた

これもびっくりだよね。

専属社員がいた。SIerなんて人を突っ込んだもの勝ちだから、上手いこと言って検証要員とかいって突っ込んだんだろうね。

ダンプがだいたい1時間くらいかけて出てくるから、それを裁断してホッチキス留めしてマーカー。

大卒の、しかも僕より先輩の社員たちだったな。

そんな人達サービス残業しているのを見て悲しくなったよね。

ネットは使えない。リファレンスは紙媒体(常に貸出中)

これはクライアント金融特有なんだと思う。

ネットは使えない。現場に入る時も持ち物チェックとかあるしな。

リファレンスは紙媒体だったよ。

でもセキュリティ観点からマスターの1冊のみ。

常に貸し出し台帳は予約で埋まっていたな。やっと借りれたのは現場離れる1週間前だったなんてこともあった。

まだまだあるんだけど、これだけでもひどい現場だったなーって思う。

そもそも設計→開発→レビュー→手戻り→設計→開発...のループだったから前に進めてないし。

最後の方レビュー適当なって品質下がってバグ生んでたし。

Gemとか外部のコードを信じきるとか、もちろん質の低いRubyエンジニアというか現場はあると思う。

それでも、やっぱりRubyのほうが未来があるよ。

この先もっともっとブラックボックスフレームワークを使うようになるかもしれないし、環境も何もかも全部おまかせでPaaSが主流になるかもしれない。

認めたくない気持ちはわかるけど、時代エンジニアも合わせていかなくちゃいけないんじゃないかな。

2016-06-19

全てのRubyエンジニアはだいたい糞である

汎用系のエンジニアからRubyエンジニアとして転職して1年。

コボラー(笑)なんて言われることも多いが、この1年で出会ったRubyエンジニアは全て糞だった。

その特徴はだいたいこの3つだ。

1.テストを甘く見ている

やれテスト自動化だ、やれテスト駆動開発だの口だけ達者なエンジニアの多いこと。

そもそもブラックボックステストホワイトボックステストを分かっていない奴が多すぎ。

テストコードカバレージが100%だったとしても実際の打鍵結果でエラーは弾けることが多いのにリリースしてしまう。

そもそもテストケース表を若いうちに書く習慣が無いからだ。

ドキュメント揶揄し机上デバッグも行わない、こんな状態で「アジャイルですから」とかドヤ顔でいってしまRubyエンジニアは糞である

2.パフォーマンスを考えない

Rubyエンジニアパフォーマンスを考えない。

どのメソッドがどれくらいの負荷なのか意識せず実装を行う。

便利だから、ただそれだけの理由なのである

そもそも自分が行おうとしているソートが何ソートなのか知っているのか?計算回数を考慮した上での実装か?

便利なメソッドがたくさんあるのは知っている。

ただ、中身くらいは知っておこうよ。

eachで回してばかりだから複雑なループ対応もできない。

新人に教えたらバカにされたけど、まずフローチャート書くようにしようぜ。

3.外部ライブラリに対する絶対的根拠の無い信頼

Gemに対する絶対的な信頼感、あれなんなの?

Githubで公開されてましたんで導入しました」じゃねーよ。

結局他のGemバッティングしているじゃねーか。

得体の知れないコードをたくさん詰め込んだプログラムをよく動かせるな。

そんで都合の悪いところだけコードを読んでオーバーライドする。

影響範囲を全く調査せず、Gem絶対神話を唱える。あれなんなの?



いや、Rubyが便利なのは認めるよ。俺だってPLIとかCOBOLより書いてて楽しいよ。

インデント合わなくてコンパイルエラーとかないしな。

でもあまりにもRubyエンジニア糞すぎだろ。

エンジニアもどき量産言語だね。どれか1つでも当てはまった奴は小学校からやり直せ。

日本の将来が心配だわ。


追記

意見がたくさんもらえて喜ばしい。

文化の違いという意見もあったが、「よくわからないけどなんかうまくいく」コードだとデバッグも大変だし不具合も起きやすい。

それで納品するのはプロとしておかしい。

主語が大きい

「だいたい」とあるだろう。全てのだいたいだ。

フローチャート

ロジックを整理するツールとしては優秀。

精神論に聞こえるかもしれないが、フローチャート書いて育ったエンジニアは頭の中でロジックの組み立てと凡その演算回数が計算できるようになるよ。

カバレージが100%だったとしても実際の打鍵結果でエラーは弾ける

あー、ここは誤タイピングだわ。

自動テストカバレージ100%です、そして画面数回触ってリリースしますーっていう奴が多いってこった。

単体だけじゃなく画面使ったテストもケース表書いて網羅性を担保しないとダメだろ。

もちろん慣れて頭に入ってくれば勘所がわかるんだが、そんな属人的ものよりもケース表書くのが無難だろう。

2016-04-21

転職は5年勤めてから

の方が良い。

後悔しかしませんよ

追記 :

プログラミング技術はある程度自分で調べればわかるから設計ベストプラクティス教えて欲しいな。さすがにTOPページでjson取ってくんのはあんま良くねーと思っちゃった。俺が作ったんだけど。

まぁ、結構勉強になったから良しとする。

追記 : 2015/08/12

社内勉強会を定期的にやってる。今日分析系の話。傾向を分析するのではなく何を分析するかが重要らしい。っ俺の考えと違うかも知れないがすごく意識が変わった。

てか思った。そもそも、傾向分析する必要あんの?減少傾向であれば回復するのは厳しくねっかほぼ無理じゃね?以下の例がうちの会社がやってること。

会員数が減った → 退会した会員の様々な傾向を分析しよう!

これはマジであん意味ない。今日の勉強会の答えは

具体的な原因を突き止めてそれらの傾向を分析する的な感じ。

でもそんなのめんどくさくね?

俺の考えは以下。

会員数が減った → SEOを強化(減った数以上に増やす)。そんなチマチマした改善工数かけんなら新しい機能新規事業を行う。

つーか、そんなに改善点があるアプリじゃないですよ、って言ってあげたかった。mixiみてよ、足跡消したりクソゲー増やしたのが原因じゃないでしょ。飽きられただけ。あとお客を動かす施策意味の無さ。メルマガ、お得系。そんなん変わんねーよアホかよ。

っかこんなん考えること自体が嫌だわ。ちゃんと考えてる同世代は偉いし優秀だわ。ホントはちゃんと考えなきゃいけないね

追記 : 2015/08/14

憂鬱でなければ仕事じゃない」

それなりに偉くなると会議が増える。僕らみたいな下っ端は「いろいろ抱えてて大変だなー」って思う。ように言い聞かせる。そもそも会議ってなんのためにやるんだろう?僕が考えた結果

「モノを実現するための話し合い」

時間も掛けた結果ってのが不透明なまま。不透明って言い方は違うかな?要はないも得ていない安定の不毛会議。これに気付いてるのは僕ら20代の連中だけ。 上記の定義だと会議夢物語を語る場だから会社楽しいかもね。そこは勘違いしちゃいけない、憂鬱でなければ仕事じゃない

追記 : 2015/08/19

会議議事録重要さ。簡単で良い。ある程度の発言をまとめておけばそれ見て答えが出るので物事スムーズにいく。延びる会社ってのはホワイトボードが多いしなー。

あとxamarinの発表。プレゼンの下手さに感動。

ほとんどライブラリ使えるの?とか知らねーよ、だいたい使えるわ。UI共通化は?出来ねーって言ったでしょ。細かいバグはありそうだけど、相当実用的。でも多分これは導入されねぇな!みんなモチベ低い!

ほかプロジェクトが詰んでたやつ、stackoverflowに載ってたっぽい。もっとGoogle翻訳使えよ!!周知しよ、難癖つけられそう笑

追記 : 2015/08/22

すごく重要な話があった。すごく憂鬱になる話。

でもプログラミングが出来る環境は維持されるみたいなんで良かった。SIerときは全員技術者だったから良かったな。っか楽。

よく技術者営業対立があるけど、極端な話、全員営業やる。全員技術者やる。どっちが良い方向になるかわかんねーよな。

営業キツイよなー、成果出なきゃやり甲斐が生まれないでしょ。

もう、みんなプログラミングやろ!楽しいよ!多分

追記 : 2015/08/24

空気が重い。卒論思い出す。

いろいろ考えるから憂鬱な話はあとに効くみたい。

この状況を覚悟してたけど、まさか想定してるなかで最悪な状況に出くわすとか笑。

「一生面倒みる覚悟がないなら助けるな」

大学教授に言われた言葉が身に染みる。多分あの人は地獄をみるだろう。

追記 : 2015/08/26

面談。褒められた。評価評価うるせぇ。評価給料からあんま興味ねーよそこには。給料転職したんじゃねーよ、前の会社の方がよっぽど給料いいわ。技術者出身経営者がいる会社に入りたかったなほんとに。

っかangularjsすごいいいなと。双方向データバインディングHTML拡張フロントと完全分離出来るのがあつい。

追記:2015/09/07

夏休み終了。海外はいいなーやっぱ。いろんな人間見てるだけで楽しーわ、ってことで憂鬱会社まり

僕が設計実装した機能を他プロジェクトに移行する案件で同期に任せてたんだけど、いろいろ未完成すぎて仕事増えた。詰みそうなとこ教えて「問題ないっすよ」って言ってたのに問題ありあり詰んだわ。nugetエグい(近々、エグいの書く)。まぁ、回避たか問題ないけどさ。

追記:2015/09/16

ちょー出世した。事業責任者的な感じ。給料めっちゃあがる。転職して半年プログラムが楽しくてひたすら組んでただけ。前の職場でも無理矢理リーダーさせられたし、無駄な運は持ってるなーと感じる。ひたすら組んでると開発効率だったり、何が出来るか、未来があるかってのを想像するのが好きなんで、それをキャッキャ言いながら楽しそうに話すことと、詰んだときゴリ押し回避方法を生み出すのが得意なんで、出来る奴だなーと思われてるっぽい。

これからはひたすらプログラム組むことは難しくなりそうだなー。あと結果と周りの目、いきなり入ってきた奴が急に出世するから嫌な感じだよね。まだ20代半ばよ、気が重すぎる。まぁ、半年後に急降下する可能性があるから気が楽になったわ。

追記:2015/09/30

今日、いろいろ発表された。なんか抜擢されたかおかしいなーって思ってて、抜擢された奴らを見たらびびった。全員、世渡り上手(俺も)。ちょっとガッカリ自分でもちょっとコード書ける方だなーと思ってたけど、それが理由ではなかったのね。まぁ、同世代スーパーエリートばかりなのになんかおかしいと思った。

もうasp mvc飽きたなー。angular楽しいからまだいいけど。

最近rails楽しいちょっとしたキュレーションサイトを構築中だけど、コード量がaspと比べるとビビるわ。複数モデル使えるとかビックリマークすげーとか。gemもコレねぇかなーとか思ったらだいたいありそう、何より日本語情報多すぎ!但し、サイトいつ出来るかなー。

追記:2015/10/15

やっぱ感情的な人はあんまりきじゃないなー。柔軟じゃなさ過ぎ。極端だけど、討論番組とか見てても感情的な人っておかしからなー。俺も感情だけで転職したけど大失敗だったし。ただ、久しぶりに会いたいって思う人は感情的な人が多い。不思議

っか雇われの身だったらなにかをやってやるって気持ちで臨むと終わるないろいろと。っかなにもしないでも金貰えることは常に頭に入れておかん人間的におかしくなるね。

追記:2015/10/19

いやーやっぱ俺のこと好かねー人多いなー。予想通りっすね。つーか底辺突っ走ってきて就活時期にアルバイトしなきゃいけねーなって思ってた俺が降格なんてビビるはずねぇだろボケ調子乗ってたら激安家賃の家にすまねーだろぅがよぅ!

って感じで愚痴はこれまで。

つーか、整合性は細かい部分じゃなくて決定した時にガツっと決めた方がいいな。まじでいちいち考慮したプログラムかいてられんよ、クソめちゃくちゃなコードになるし。そういう点ではjsはすげー勉強になった。ただ、結構プログラム本質を突いていてjs馬鹿に出来んなーと身を持って感じました。常に整合性を保つってのはその場しのぎのコードになりますね。

追記:2015/12/07

好きなことでお金を稼ぐって非常に難しいことがわかった。俺が転職したのもスキルアップじゃなくて好きなことやりたいって気持ちだったのね。すげー勘違いしてた。後悔してもしょうがないから資格を取ろう。

追記:2016/02/11

小学生の頃と悩みが同じ。希望が持てた一年前の方がずっとマシだ

転職は5年勤めてから

の方が良い。

後悔しかしませんよ

追記 :

プログラミング技術はある程度自分で調べればわかるから設計ベストプラクティス教えて欲しいな。さすがにTOPページでjson取ってくんのはあんま良くねーと思っちゃった。俺が作ったんだけど。

まぁ、結構勉強になったから良しとする。

追記 : 2015/08/12

社内勉強会を定期的にやってる。今日分析系の話。傾向を分析するのではなく何を分析するかが重要らしい。っ俺の考えと違うかも知れないがすごく意識が変わった。

てか思った。そもそも、傾向分析する必要あんの?減少傾向であれば回復するのは厳しくねっかほぼ無理じゃね?以下の例がうちの会社がやってること。

会員数が減った → 退会した会員の様々な傾向を分析しよう!

これはマジであん意味ない。今日の勉強会の答えは

具体的な原因を突き止めてそれらの傾向を分析する的な感じ。

でもそんなのめんどくさくね?

俺の考えは以下。

会員数が減った → SEOを強化(減った数以上に増やす)。そんなチマチマした改善工数かけんなら新しい機能新規事業を行う。

つーか、そんなに改善点があるアプリじゃないですよ、って言ってあげたかった。mixiみてよ、足跡消したりクソゲー増やしたのが原因じゃないでしょ。飽きられただけ。あとお客を動かす施策意味の無さ。メルマガ、お得系。そんなん変わんねーよアホかよ。

っかこんなん考えること自体が嫌だわ。ちゃんと考えてる同世代は偉いし優秀だわ。ホントはちゃんと考えなきゃいけないね

追記 : 2015/08/14

憂鬱でなければ仕事じゃない」

それなりに偉くなると会議が増える。僕らみたいな下っ端は「いろいろ抱えてて大変だなー」って思う。ように言い聞かせる。そもそも会議ってなんのためにやるんだろう?僕が考えた結果

「モノを実現するための話し合い」

時間も掛けた結果ってのが不透明なまま。不透明って言い方は違うかな?要はないも得ていない安定の不毛会議。これに気付いてるのは僕ら20代の連中だけ。 上記の定義だと会議夢物語を語る場だから会社楽しいかもね。そこは勘違いしちゃいけない、憂鬱でなければ仕事じゃない

追記 : 2015/08/19

会議議事録重要さ。簡単で良い。ある程度の発言をまとめておけばそれ見て答えが出るので物事スムーズにいく。延びる会社ってのはホワイトボードが多いしなー。

あとxamarinの発表。プレゼンの下手さに感動。

ほとんどライブラリ使えるの?とか知らねーよ、だいたい使えるわ。UI共通化は?出来ねーって言ったでしょ。細かいバグはありそうだけど、相当実用的。でも多分これは導入されねぇな!みんなモチベ低い!

ほかプロジェクトが詰んでたやつ、stackoverflowに載ってたっぽい。もっとGoogle翻訳使えよ!!周知しよ、難癖つけられそう笑

追記 : 2015/08/22

すごく重要な話があった。すごく憂鬱になる話。

でもプログラミングが出来る環境は維持されるみたいなんで良かった。SIerときは全員技術者だったから良かったな。っか楽。

よく技術者営業対立があるけど、極端な話、全員営業やる。全員技術者やる。どっちが良い方向になるかわかんねーよな。

営業キツイよなー、成果出なきゃやり甲斐が生まれないでしょ。

もう、みんなプログラミングやろ!楽しいよ!多分

追記 : 2015/08/24

空気が重い。卒論思い出す。

いろいろ考えるから憂鬱な話はあとに効くみたい。

この状況を覚悟してたけど、まさか想定してるなかで最悪な状況に出くわすとか笑。

「一生面倒みる覚悟がないなら助けるな」

大学教授に言われた言葉が身に染みる。多分あの人は地獄をみるだろう。

追記 : 2015/08/26

面談。褒められた。評価評価うるせぇ。評価給料からあんま興味ねーよそこには。給料転職したんじゃねーよ、前の会社の方がよっぽど給料いいわ。技術者出身経営者がいる会社に入りたかったなほんとに。

っかangularjsすごいいいなと。双方向データバインディングHTML拡張フロントと完全分離出来るのがあつい。

追記:2015/09/07

夏休み終了。海外はいいなーやっぱ。いろんな人間見てるだけで楽しーわ、ってことで憂鬱会社まり

僕が設計実装した機能を他プロジェクトに移行する案件で同期に任せてたんだけど、いろいろ未完成すぎて仕事増えた。詰みそうなとこ教えて「問題ないっすよ」って言ってたのに問題ありあり詰んだわ。nugetエグい(近々、エグいの書く)。まぁ、回避たか問題ないけどさ。

追記:2015/09/16

ちょー出世した。事業責任者的な感じ。給料めっちゃあがる。転職して半年プログラムが楽しくてひたすら組んでただけ。前の職場でも無理矢理リーダーさせられたし、無駄な運は持ってるなーと感じる。ひたすら組んでると開発効率だったり、何が出来るか、未来があるかってのを想像するのが好きなんで、それをキャッキャ言いながら楽しそうに話すことと、詰んだときゴリ押し回避方法を生み出すのが得意なんで、出来る奴だなーと思われてるっぽい。

これからはひたすらプログラム組むことは難しくなりそうだなー。あと結果と周りの目、いきなり入ってきた奴が急に出世するから嫌な感じだよね。まだ20代半ばよ、気が重すぎる。まぁ、半年後に急降下する可能性があるから気が楽になったわ。

追記:2015/09/30

今日、いろいろ発表された。なんか抜擢されたかおかしいなーって思ってて、抜擢された奴らを見たらびびった。全員、世渡り上手(俺も)。ちょっとガッカリ自分でもちょっとコード書ける方だなーと思ってたけど、それが理由ではなかったのね。まぁ、同世代スーパーエリートばかりなのになんかおかしいと思った。

もうasp mvc飽きたなー。angular楽しいからまだいいけど。

最近rails楽しいちょっとしたキュレーションサイトを構築中だけど、コード量がaspと比べるとビビるわ。複数モデル使えるとかビックリマークすげーとか。gemもコレねぇかなーとか思ったらだいたいありそう、何より日本語情報多すぎ!但し、サイトいつ出来るかなー。

追記:2015/10/15

やっぱ感情的な人はあんまりきじゃないなー。柔軟じゃなさ過ぎ。極端だけど、討論番組とか見てても感情的な人っておかしからなー。俺も感情だけで転職したけど大失敗だったし。ただ、久しぶりに会いたいって思う人は感情的な人が多い。不思議

っか雇われの身だったらなにかをやってやるって気持ちで臨むと終わるないろいろと。っかなにもしないでも金貰えることは常に頭に入れておかん人間的におかしくなるね。

追記:2015/10/19

いやーやっぱ俺のこと好かねー人多いなー。予想通りっすね。つーか底辺突っ走ってきて就活時期にアルバイトしなきゃいけねーなって思ってた俺が降格なんてビビるはずねぇだろボケ調子乗ってたら激安家賃の家にすまねーだろぅがよぅ!

って感じで愚痴はこれまで。

つーか、整合性は細かい部分じゃなくて決定した時にガツっと決めた方がいいな。まじでいちいち考慮したプログラムかいてられんよ、クソめちゃくちゃなコードになるし。そういう点ではjsはすげー勉強になった。ただ、結構プログラム本質を突いていてjs馬鹿に出来んなーと身を持って感じました。常に整合性を保つってのはその場しのぎのコードになりますね。

追記:2015/12/07

好きなことでお金を稼ぐって非常に難しいことがわかった。俺が転職したのもスキルアップじゃなくて好きなことやりたいって気持ちだったのね。すげー勘違いしてた。後悔してもしょうがないから資格を取ろう。

追記:2016/02/11

小学生の頃と悩みが同じ。希望が持てた一年前の方がずっとマシだ

2015-11-01

いい感じの動画紹介サイトを作って、高速化した話

作ったもの

大人向けのエンタメ動画キュレーションするサイトを作ってみました。

18歳未満の人はみちゃだめです

http://videovdo.com/

高速化の話

このサイトRailsで作ってherokuに乗せてみたんですが、いかんせん遅い。

もちろんheroku札束で叩けばいくらでも早くなるんだけどそんなに予算もないし、そもそもそんなお金あったらこんなことしてない。

なのでどうにかしてお金を掛けずにサイト高速化する方法を考えてたら1つアイデアが浮かんだのです。

それはサイト全体をCDNのCloudfrontに突っ込んでしまう事。

やり方

ルートドメインDNS設定のCNAMEで、Cloudfrontドメイン指定します。

そしてCloudfrontオリジンherokuドメイン指定する。

こうすることでCSSとか画像ファイルだけでなく、HTMLも含めて全部のファイルキャッシュすることができます

そしてCloudfrontの設定で、HTMLファイル10分とか1時間とか割と短めに設定して、

CSSとかJSとかは、Railsで作っているとMD5キャッシュが効いていて、勝手キャッシュ無効化されるので、

1か月とかを指定すればよい。

効果

効果としては、heroku単体でやるとHTMLファイルの応答が600msぐらいかかっていたのが、Cloudfrontキャッシュさせると60msぐらいで帰ってくる。

もう超早い。10倍速い。

あとgzip配信したいので、gemheroku-deflaterを入れる。

このgemはすごくて、herokuに乗っていると勝手gzip圧縮してくれる。

これによってCloudfrontの利用料を節約する。

料金

僕のサイト場合、このherokuサーバーから配信しているのは、HTMLCSSが1ファイルとあと画像が1つで合わせて10kBぐらいしかない。

こんだけだと、Cloudfrontの料金は100万PVでも1000円いかないぐらい。

heroku札束で叩くのと違って、従量課金なのであらかじめ高いお金を払っておく必要もないし、

100万PV1000円ならまあ割と現実的価格なので、当分の間はこれで運営していこうかと思う。

2015-07-22

フィボナッチ数列クイックソート実装ができません

海外記事で、プログラマ採用試験タイトルのような実装試験に出す、というのをたまにみる。

こういうの見るたびに、答えがわからないので自分はまず落ちるだろうなと思う。

かと言って自分底辺 && 向上心ゼロで使い物にならないか?と自問すると違うと思う。

今の会社Railsサービスを少なくとも4つ以上リリースしているし、バージョンアップなどの保守が2年以上できている。プライベートgemを作ったりしているし、サーバの小規模なサーバであれば運用もできるくらいのLinuxの知識(小並感)もある。何よりプログラムを通して問題解決をするのが好きだ。

競技プログラミングには興味あるけど、今はLinuxへの興味のほうが強い。

話を戻すけど、そういう試験を設けている会社は、技術顧問とかCTO級も求めているんだろうか?

単純な作業者を求めている場合は、このような試験は課さない?

フィボナッチ数列クイックソートのような原理に興味・関心を持っているかを推し量る目的

2015-05-19

linuxカーネルアップデートってめっちゃ簡単

sudo apt-cache search linux-image  
apt-get install linux-image-4.0.0-1-amd64

してからrebootしたらもう新しいカーネルよ。

debiansiddockerを使うためにはカーネルバージョンをあげろ、とでたのでカーネルの上げ方を渋々調べためっちゃ簡単でワロタ

このdebian仮想環境 on Macを使っているんだけど、linuxホストPCとして使いたいなって思った。

MacってC Native Extentiongemインストール失敗ばっかするしで開発PCには向いていないんじゃないのかなって思ってきたよ。

2015-05-13

http://anond.hatelabo.jp/20150513131421

そんなのよりオープンクラスだろ、問題は。

標準ライブラリ他人の書いたクラス自由拡張上書き可能なんて恐ろしすぎる。

そんな言語gemでばしばしプラグイン入れてソフト作るなんて狂気の沙汰。

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