yutori:call()を実行します。yutori:sushi(プロセス数, 回数)を入力します。yutori:sushi(プロセス数, 回数)を実行してしまいました。 |
 |
バイキルト→アイスフォース→バードシュートが一番効率がいい
ベンダー「Struts2のバージョンを上げたい」JINS「それ、何が変わるの？いくらかかるの？」ベンダー「機能は変わりません。セキュリティが向上します。～百万円です。」JINS「機能増えないんだ。じゃ、やらなくていい」#システム開発会社として善良なる管理者
— hotchemiさん (@mike_neck) 2013年5月1日
は各章の最後にエクササイズがあって、spawnという関数を用いて関数を実行すると、!演算子を用いることで、-module(fib).
-export([fib/1]).
fib(N) when N < 2 -> 1;
fib(N) ->
fib(N - 1) + fib(N - 2).
3> timer:tc(fib, fib, [10]).
{11,89}
4> timer:tc(fib, fib, [12]).
{24,233}
5> timer:tc(fib, fib, [14]).
{61,610}
6> timer:tc(fib, fib, [20]).
{1546,10946}
timer:tc関数の戻り値の一つ目の要素が実行時間(ms)です。fib:fib関数を少し修正して、3> timer:tc(fib, fib, [10]).
{2889,89}
4> timer:tc(fib, fib, [12]).
{5109,233}
5> timer:tc(fib, fib, [14]).
{5684,610}
6> timer:tc(fib, fib, [20]).
{132777,10946}
7> timer:tc(fib, fib, [10]).
too many processesだってｗfibはひとつのプロセスでやる奴。cfibは二つのプロセスでやる奴。ccfibは四つのプロセスでやる奴。厨二病のみけ様
お世話になります。
株式会社hoge採用担当です。
この度はオファーへのご返信、誠にありがとうございます。
大変恐縮ですが、勤務時間は全社員共通の8時間が定時となり
個別の調整は難しい状況です。
大変残念ですが、ご了承いただきたく存じます。
また何か機会がございましたら、その際は何卒よろしくお願いいたします。
株式会社hoge
採用担当
> ソフトウェアの継続的インテグレーションに興味があるので応募しました。
>
> 【アピール】
> JUnit/Groovy/Gradle/Maven/Spock/Selenium/HP Quick Test Professionalのスキルがあります。
> また、JavascriptのテストをJavaで実行できるようなライブラリーの作成もしております。
>
> 【考慮頂きたい事項】
> うつ病のため長時間の勤務ができません。
> 勤務時間について調整願えますでしょうか？
厨二病のみけ様
下記の件で、Ａ．Ｃ．に関しては客先常駐になるためお約束できません。
申し訳ございませんが、面接はなしとさせていただきます。
オファーに対し返信していただきましたが、
ご希望にそえず申し訳ありませんでした。
> 第1希望：４月２３日 １３時スタート～１７時スタートまで
> 第2希望：４月２４日 １３時スタート～１７時スタートまで
>
> ★面接前に質問・相談したい
> A. 現在うつ病を患っているため
> (自立支援医療制度(精神)適用済み、障害者手帳申請済み、障害者年金申請中)
> (1)勤務時間を１１：００～１７：００（途中１時間休憩含む）とすることはできないでしょうか？
> (2)勤務地について、都内限定にしてもらうことは可能でしょうか？
>
> B. 僕はJavaの専門プログラマーです。
> (1)PHP、C#、F#の案件はやりません。
> (2)Windowsは開発生産性がわるいため、Macintoshでの開発を希望します。
> (3)eclipseは開発生産性に乏しいため、JetBrains IntelliJ IDEAでの開発を希望します。
>
> C. 腰痛持ちです。(過去にぎっくり腰を数回していて、くせになっています。)
> (1)アーロンチェアと言わないまでも、腰痛にならない椅子での勤務を希望します。
>
> D. キャリアパスについて
> (1)プログラマーの価値を向上させたいという思想で生きていますので、
> プロジェクトマネージャーや何もできないエス・イーというポジションにはつきません。
>
> E. プロジェクト管理について
> (1) Atlassian JIRAでのプロジェクト管理を希望します。
> (2) Atlassian Confluenceでのドキュメント管理を希望します。
> (3) Gitでのバージョン管理を希望します。(svn、cvs、vssは使えますが、希望しません)
> (4) JenkinsあるいはTeam Cityでのビルドを希望します。
>
突然のメールにて失礼致します。 株式会社■■ 代表取締役の◯◯と申します。
私は大袈裟ではなく近いうちに日本からプログラミングの仕事がなくなる日がくるのではな
いかと考えています。理由は二つあります。
ひとつは、オフショア開発の増加です。インド、中国で注目され始めたオフショア開発ですが、
リーマンショック以降情報システム業界の仕事量が激減した年でも、その発注量は増え続け
ています。しかも、発注先もベトナム、フィリピン、ミャンマーと次々に広がっています。
もうひとつの理由は、セールスフォースに代表されるsaas環境の発達です。触った事のある人
であればわかると思いますが、ノンプログラミングで大概の事が実現できるのです。
このような環境下、あなたは本当に今のままのキャリアプランで大丈夫でしょうか？
■■では、会社として環境の変化に対応し、技術者がキャリアアップを重ねながら存在
意義を保つ環境を整えました。
馬鹿ですか？
無知・無学・無能で人を使い捨ての駒としてしか考えていない筋脳鬼畜馬鹿とは一緒に仕事できないので辞退します。
(1)オフショアについて
オフショア開発のブリッジSEの経験をしていますが、
オフショアで開発したプログラムのほとんどは日本で書きなおされます。
その理由は日本語という言語が、言語学的に特殊すぎて
機械翻訳が難しいためです。
そのためオフショア先では誤解を元に作成されたプログラムが量産され、
結果、日本人がプログラムを修正するという事例が多数発生しています。
したがって、どんなにオフショアにプログラム開発を依頼しても、
日本人がプログラムを修正するという作業がある限り、
プログラマーが不要になるということはありえないと考えております。
また、当初の見積もりコストの１０倍に膨れ上がったプロジェクトを
僕はいくつか知っています。
これらの原因となっているオフショア先のプログラム開発の能力については、
オフショア先となるアジア各国では、
プログラムをちゃんと書くための書籍類が不足していて、
(それは各国の通貨がドルに対して弱いため)
・リファクタリングが可能なコード
・変更に強いコード
・ちゃんとテストコードのあるコード
を書く能力が乏しいという事実があります。
実際に僕はインドネシアやベトナムの書籍店を回ってみましたが、
プログラミングに関する書籍は非常に少ないばかりか、
プロフェッショナルの使用に耐えうるような書籍はほぼ皆無でした。
オフショア開発で成功するための必要最低な条件は、僕の経験上以下の３つになります。
・時差が少ない
・言語間の壁が小さい(英語-スペイン語など)
・オフショア先でもプログラミングに関するちゃんとした書籍が入手できる
- 10日でできるAndroidのような書籍は論外です。
- マーティン・ファウラーなどの書籍のことを指しています。
上記の事実を勘案すると、東アジア圏ではオフショア開発が
成功するというのはほとんど不可能に近いです。
上記の条件を満たせるオフショア環境は今のところ、
US-ブラジルの間だけではないかと存じています。
実際、ブラジルでオフショア開発が成功したという事例はよく聞きます。
貴殿のプログラマー不要説がこれらの必要条件を精査した結果でのものと
思えるほどには説得力のない説明であったので、
貴殿が業界の勉強や実体の調査をおこなっていないと判断するに至りました。
(2)Google Apps、GeNexus、Salesforce等のプログラミングレスアプリケーションについて
これらの既存アプリケーションの組み合わせによる業務アプリ作成は、
フルスクラッチからの開発よりもかなり高速な開発を実現できるのは事実です。
しかし、Salesforceを僕よりもご存知であろうとおもいますが、
業務的に性格を期すアプリケーションを構築するためには、
(例えば受注が成立した場合に関係者にメールを送付して、
現在ある在庫を確保するという業務)
Google AppsではJavascript、
GeNexusでは独自のプログラミング言語、
SalesforceではJavaに似た独自のプログラミング言語
でのカスタマイズが必要になります。
これらはC、Java、C#等の低水準の言語で恩恵があったIDEのサポートを得られず、
入力補完が効かない、型安全でないという生産性低下の要因を抱えています。
入力補完がない型安全でないということは、
コンパイル時にプログラムが正しいことを証明できず、
実行時にエラーとして判明するため、
不具合箇所の検出、修正に多大なるコストがかかります。
C、Java、C#といった言語の場合、
見かけ上は開発コストがかかるように見えますが、
プログラミングレス言語に比べて、
バグ検出・修正コストを調整できるメリットがあり、
コストは大して変わらないと存じます。
以上二点から貴殿のプログラマー不要という考えには同意できかねるため、
本オファーを辞退させていただきたいと思います。
梅本洋一さん死去 「カイエ・デュ・シネマ・ジャポン」（朝日新聞デジタル） - Y!ニュース headlines.yahoo.co.jp/hl?a=20130312-… この先生にはお世話になったな…ご冥福をお祈りします
— (ΦωΦ)さん (@mike_neck) 2013年3月12日
GroovyASTTransformationのAnnotation Based ASTTransformationAnnotation Based ASTTransformationを中心に発表しました。GroovyASTTransformationを初めて書く場合には非常に導入しやすいからです。@ToString、@EqualsAndHashCode、@Canonical、@Log、@Log4j、@Slf4j、@Singleton、@Delegate)String namedef ageのようなもの)0"groovy"true)list.size()、builder.append('c'))String name = "hoge";)String name = builder.toString();)if (condition) {//do something} else {//do another thing} )return builder.toString();)
Refactorを使いましょう。
Refactor → Change Signature... を選ぶか、⌘ + F6を押します。
Refactorボタンを押せば、自動的にメソッドとそのメソッドを使用している部分が変更されます。
⌥ + Enterする。
surrond with try-with-resources blockを選ぶ。
try(...)で囲まれたけど、まだ赤いエラーが出たままなので、⌥ + Enterする。
Add catch close(s)を選ぶ。
catchが多いとアレなんで、⌥ + Enterして、
Collapse catch closesを選んで、まとめる。
try()の部分をどうにかしましょう。try()のところの赤線の範囲にカーソルを当てて、⌥ + Enterを押します。
Add Catch Clause(S)を選択します。
factory.createXML…の部分にカーソルをあてて、⌥ + Enterを押します。
Add Catch Clause(S)を選択します。
catchのあたりがドドメ色(どんな色？？？)になっています。catchのあたりにカーソルを合わせて、⌥ + Enterを押します。
Collapse 'catch' blocksを選択します。
throwsをつけるのも、⌥ + Enter → やりたいことの順番です。
assertThat(hoge, is(foo));ってのを書くときはこんな感じで書いています。asまで入力
assertで一旦入力補完を完了する。
Thatをassertの直後に付け加える。
org.junitのAssert.assertThatを選ぶ。
is と入力する。
is に括弧を付けて、括弧の中にカーソルを合わせる。
Matchers.is を選ぶ(他にもいろいろ使えるMatcher が使えるため)。
