「PHP」を含む日記 RSS

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

2017-03-23

PHP真実

PHPマスコットキャラクターとして象を採用している、ということは増田フレンズもご存知の通りだと思うが、なぜ象なのだろうか?

PHP」という文字列が象に見えるからか? いや、それだけではない。

キーボードPHPのそれぞれ隣にあるキーを打ってみよう。

@...j...@....そこには君と向き合う象のフレンズが見えているはずだ。

2017-03-19

http://anond.hatelabo.jp/20170319132149

日本のお役所PDF大好きなのは、知っている。霞ヶ関から吐き出される有効資料は、ほぼpdf

一方で、e-statなどでは、ネ申エクセルや方眼エクセルとは、別の方向でcsvデータを公開している。

今、株価が上昇しているIT企業様は、PDFhtmlとを比べるような使い方はしていないのでは?

世界は、IT企業htmlPDFとを比べたらどちらを重用しているのか?

  

googlejava script 推しのJQueryを良く使ってるし、これからは、人工知能時代からxml形式とか、マークアップ言語は、良く出てくると思うよ。

Facebookphpなんでしょう?リア充御用達で、Twitterよりも株価資本も安定している。

これからは、you tubeとかLINEみたいなツールがどんどん出てくるから、先のことは分からないよね。

オープンソースでもGit hubみたいなツールが使われているんだし。。  

そう言えば、perlcgiは、ほぼお亡くなりになりましたね。

2017-03-18

チェックボックスにチェックしないと値が送られない問題

http://anond.hatelabo.jp/20170313223351 の続き

PHPクッキー勉強をしているのだけれども、

買ってきたテキスト通りに作ってもエラーが出る。

http://elegumi.com/benno9/1932/

↑によると、どうやらチェックボックスオフの時は(空のデータすらも)データが送られないようで、

代入の際にエラーになるようであった。

今はインターネットがあるから、すぐ知見が得られるけども、

本の通りに作ってもうまくいかないことがあるってどうなのか!

本の帯には「3万人に読まれた」とか描いてあるけど、3万人苦しんだぞ多分。

2017-03-13

PHPすごい

Perlよりも簡単にできる

2017-03-12

書き換える必要なくね?

大企業銀行で、昔から動いている基幹システムは、大抵メインフレームCOBOLの組み合わせである

それをここ十年くらい、リプレースx86サーバJavaという構成に変更することが多い。

しかし、ハード汎用機からオープン系になるのはともかく、プログラムを別の言語に書き換えるとか、誰も幸せになる気がしない。

ぶっちゃけCOBOLCOBOLのまま移植し、今後も改修を続けるほうが、長い目で見たコストも低くなるのでは?と思うのだ。

その理由はこうだ。


COBOLで書かれたバッチ処理は、設計書の書式がフローチャートであることが多い。

勿論ロクに設計書がない場合もあるだろうけど、いずれにせよCOBOL文法は、「普通の人にとっての仕事らしい仕事」をそのまま入れ子状のフローチャート(分岐の先が別のフローチャート参照みたいになってるやつね)に書き表したものである

そういうモノが既にある企業銀行文化において、当然発注側は担当者からお偉いさんまでCOBOLerフローチャート脳だし、新しいシステム設計でもそれを踏襲しようとする。

というか踏襲すること前提じゃないと設計書をレビューできない。

UMLで考えるようなパラダイムシフトはまず不可能なので、それを求めるのは受注者の傲慢だろう。

というわけで、受注した大手SIerは、ほぼ確実にフローチャートもしくはそれに準じる記法設計書で処理を組み上げざるを得なくなる。


そうなると、実装フローチャート設計を基にコードを書くわけだが、こういう設計ハッカー文化で発展してきた言語(FortranC/C++Javaという流れと、PerlからPythonPHPというインタプリタ系の諸言語)との相性が最悪である

設計とは実装を楽にするために書くのに、これらの言語において、フローチャート設計は役に立たないどころか、邪魔しかない。

からFortranしかなかった頃から、本物のプログラマ達はフローチャートdisってきたわけである

ちなみに筆者はハッカー文化が生み出した恩恵に敬意を示すし、実際とても好きという立場である

しかし、「普通人達普通思考からはかけ離れ過ぎているという意味で、「普通人達普通仕事」をシステム化する時にどこまで役に立つかについては、非常に懐疑的に見ている。

…いささか話が脱線してしまったが、とにかくフローチャートで上がってきた設計書でコードを書くならCOBOLアセンブラ選択すべきだし、それで書けないなら書く意味が無いくらいに思ったほうが良い気がする。


というわけで、自分COBOLからリプレース案件は、その根本的な愚かしさを抱えている現状を見るに、今後一切関わる気はない。

COBOLリプレースするのでない限りは。

2017-03-07

Perl挫折したので

PHP勉強しようと思う。南無。

2017-02-28

[][]無職増田転職活動まとめ

前回までのあらすじ

無職となり街を彷徨っていた@saitamasaitamaこと無職増田仕事を探していた。

しか33歳という高齢の上見た目がキモくて金もないおっさんであるが故誰にも雇われることはなく――

だが最終的に仕事が決定したため、無職増田が実際に行った転職活動の内容についてまとめてみようと思う。

無職増田って何者?

ただのキモくて金のない33歳のおっさん。ただし20歳の頃からエンジニアとして働いているのでそれなりに結構技術には自信があるPHPおじさん。つまりは実質高卒であり、学歴は酷いものである

大学中退している手前学歴コンプであり、東大付近を通りかかるとインテリっぽい女子大石泉ちゃんみたいなの)がいないかどうかを目を皿のようにして見張ったりすることも。

性格的にはキモくて金のないおっさん類型とされるような中途半端な会話力の上にキモくてウザい語りをぶちまけた「女子絶対彼にしたくないと思う男性タイプ」そのもの

無職から仕事が決まったまでのスケジュール

どんな会社とどんな面談をしたか(全13社)

時系列順に記す。会社名は当然伏せます

スマホゲームを作っている会社様と面談。割かし上手く喋れたとは思ったが、「ウチの社風とおまんスタイルは合ってねーわ」で終了。

と金額的に平凡なpaizaにおいてかなりの好待遇募集していた会社様と面談。喋れはしたが「おまえコミュ力不安あるで」で終了。

VRやってる会社に入れたらいいなあポワワとその時は思っていた。ワイ自体映像系のスキルはあまりないので「そもそもスキルマッチしとらんわ」で終了。

WEBサービスを立ち上げたい、みたいな募集要項があったので応募。(ワイも会社立ち上げたいので)話はできても「お前のコミュ力なんか怪しい」で終了。

ゲーム好き集まれ、みたいな募集要項だったので応募。かなり良い対応をしてもらえて「ならちょい試しでどや?」みたいな話をいただいた。正直今回のようなことが無ければここにお世話になってたかもしれない。

応募してから採用要綱見直してみたら必須スキルとされるものを割と満たしていないことが発覚した。熱意で押せばみたいなこともあるが、ノンスキルおじさんをやる気で誤魔化して売りつけることはしたくないので面談で「わりいけどこちらの話を進めるのは無理そうだわ」ということでサレンドアップ。

WEB系っぽい業態なのになぜかUnity/VRという不思議スキル募集していたので応募。案の定「そういう案件はこれから増えるからしれんけど今のところはそんなない」みたいな話をしていた。が、話自体は上手くできたので担当者様的には好感触らしく、二次面談まで行った。

割と根掘り葉掘り面談の経緯や年収希望などを聴き、さらに実地でペーパーにコードを書かせるという暴挙を行っていた。ペーパーテスト難易度自体はそれほどではないものの、紙にコードを書くこと自体が激烈に難易度が高いため、3問中1問を完全に落とした。にも拘わらず「めっちゃやる気あるしポテンシャルも高そう」との評価。ワイの何を見たのか。

  • I社(ゲーム系)→結果は貰ってないけど辞退

古くからソーシャルゲーム運営をやっているところ。ワイもソーシャル系なのでスキル的には100%マッチしているが、保守運営という仕事があまり好きではないため敬遠することにした。ここからがレバテック案件

結構からスマホソーシャルゲーム運営開発をやっているところ。なのでほかのソーシャル系とは違うスキルを求められていたのだが、なんだかんだで求められているものは満たしているらしく商談がまとまった。新規開発なのもワイにとってポイントが高かった。

GREE/Mobageではないプラットフォームで中堅どころの立ち位置にいる会社様。ワイをどういう目的で起用したいのかが見えず、話も割とすれ違ってた。

これについてはあんまり語りたくない。ワイの苦手な<威圧するタイプの人>が相手だった。

twitterからスカウトに至った謎ベンチャー様。話を聞くと結構壮大な話で冒険はできそうというところでワイのテンションagaってる中で内定まで頂いて申し訳なかったのだが、今回他の内定を貰っていたところ等と比較して総合的な判断で(主に金)辞退という結果になった。

まとめると?

3週間で13社と面談してそのうち3社位から内定貰えた。

転職活動期間は実質25日。無職期間は実質20前後(稼働は3月からなので)。

心が折れそうになることもあったが、一応のこと転職成功したと言えるかもしれない。

レバテック様に関しては今回仕事を決めたのがレバテックであることと度々名前を出してしまっていた手前、こちらの記事で「大変弊社の助けとなった」ということで感謝の礼に換えさせて頂きたいと存じます。まる。

来週からは「KKO増田微妙冒険」が始まります

例のごとくNDA情報はおろか愚痴も一切漏らさないので、そこんところ期待する方はお早めにご退場願います

これからもKKO増田と、これから無職になる新しい無職増田たちをよろしくお願いいたします。

2017-02-23

.iniファイル

このまえSIerPHPプロジェクトで、パラメーターを設定ファイルに外だししようって話になって「.iniファイルの読込ルーチンはどうする? だれか作れる? ○○さんがもってるかも」って話になってたから、PHPなら標準でxmljsonの読込関数がありますよって言ってみたけど「あ、こいつまた小難しいこと言ってる」みたいな空気になって流されたな。

ホットエントリ内閣府CSVやばいって記事で思い出した。

2017-02-21

http://anond.hatelabo.jp/20170221234633

RoRはそんなにおちんぎん高くないし案件も無いぞ。Pythonも同様。バックエンド言語は今のところPHP/Javaの二択やで。

PHPできるおじさんはJavaも大体できるから、そっから先は本当に好みやな。

あえてJavaScriptなのはフロントサーバー需要が高まってるからあえて特化してみるとおじさんパワー(加齢臭)が高まるかな? と思ってのことだ。

実際、サーバフロントを一つの言語にまとめたいっていう需要結構ある。

2017-02-19

[]さあ、月曜日からまた転職活動だ!

いまだに無職増田です。でも本格的に転職活動を始めたついでにレバテックなるもの登録してみました。レバテックゆうんは多分登録型の派遣とか請け負いのコンサルをしてくれる会社です。

その会社webから登録したら、そのあと電話かかってきて「おうお前いい度胸してんなァ。ちょいシブヤまで来いや」と脅されたので

月曜は渋谷まで行ってケジメをつけてきます。僕の小指が失われないかどうか心配ですが、なんとか交渉成立するといいですね。

それはともかくとして、弊社はPHPおじさんなんですがやっぱりモダンJavaScriptおじさんにも転向しようかなと思うんですが、フレームワーク等々が多すぎてどれを選べばいいかよくわからなくて困ってます

apt-get一発でインストールできてなおかつ一番シンプルコード記述量も少ないフロントエンドの何かってないでしょうか。

ぶっちゃけどのフレームワークJavaScript以外の方言的な記述が多すぎてどれもシンプルはいいがたい気がします。

PHPおじさん的にはいまだに「JQueryでよくね?」と思うんですが、もう2017年ですしね。

というわけで、増田さんたちのおすすめJavascriptフロントエンドをご紹介ください。

紹介いただきました情報採用された方には無職増田オリジナルのクソ雑魚ナメクジイラスト差し上げたいと思います

よろしくお願いいたします。

2017-02-15

webからsier(孫請け)に戻ることにした

客先常駐が嫌だった

仕事でもgitとかphpをやりたかった

でも実際働いてみて割に合わないと感じた。

休んだら自宅からやらなきゃ行けないような仕事も多かったし

残業代もでないし

何より定時で帰りたい

2017-02-14

[]初めまして増田さんたち。今日から無職増田だよ!

初めましての人は初めまして、お久しぶりの人はお久しぶり。本日より無職になりました増田です。

せっかくだからtwitterアカウントも公開しておきます。@saitamasaitamaです。

増田ロートルPHPおじさんっぽい人間がいたかな? と思ったら大体私が犯人でした。ちなみに年齢は33歳です。

いやー、ついに無職なっちまいましたよ! 今まで有休消化中だったから昨日と今日とで生活ダイナミックに変わるってことはないんですが、収入源が途切れるってすっごく心細くなるよね!

ってか転職活動は在職の内にやっておくべきだね! 

はてさて。拙者を雇ってくれる企業はこれから先現れてくれるでしょうか。

もしくは、拙者は無事起業できるでしょうか。これから先定期的に増田で報告していこうと思いますので、よろしくお願いいたします。

2017-02-10

http://anond.hatelabo.jp/20170210130822

ああ、まあそれ未経験じゃねーから

Javaプログラミング工程管理ができる経験者として応募していいよ。

まあ1人でMySQLRailsPHP(Laravel)の環境ぐらいは作れたほうがいいけど。

http://anond.hatelabo.jp/20170210112438

最初SIに入って教育受けたあとにWebページ作成受託案件プロジェクトとか経験して

RubyPHP書けるようになったら転職すればいい

2017-02-05

静的型チェックのない時点で五十歩百歩な感じだから

JSやらPerlやらPHPの間で、どれがガバガバか争われてもって細かい話ににしか見えない。

2017-02-03

スマホアプリを俺しか作れないことになっているが

以前、上司が出したスマホアプリアイデアを俺が実装して、それがちょっとした商売になった。

でも、おれがそれ専属になれるほどは稼げてはいない。

上司自分アイデアをなんとかモノにしたいから、おれにプライベート時間を使って開発してほしいみたいなことを言う。

気が向かないから「やります、やります」と言ってなかなか手をつけない。

俺抜きでなんとかしようとして、付き合いのある会社アプリクラウドしましょうみたいな話をもっていったみたいだけど、その会社PHPWebの開発をしてる会社からスマホアプリはよくわからないみたい。

(俺の知らないところで動いてるからくわしいことはよくわからんけど)

上司は内心は俺を気に食わないから、俺抜きで動きたいんだけど、俺しかスマホアプリを作れないからそれができない。

でも、俺だって入門書を読んで簡単アプリしか作れないレベル

社内の鈴木さんや池田さんあたりのコードを書ける人に、一週間くらい時間Macを与えて「アプリの作り方を勉強しろ」って言ったらすぐ作れるようになると思うけど、開発できないからそういうのわからないんだろうな。

2017-01-31

【開発】アンテナサイトのジェネレーターを作った

しがないWebエンジニアをしています

今年の1月からチマチマ作っていたアンテナサイトのジェネレータを公開しました

アンテナサイトメーカー

http://antena-mk.com/home

サービス説明

お好みのRSS登録するだけであなただけのアンテナサイトの完成です。

自身広告掲載できるので、お小遣い稼ぎもできます

Google Analyticsコードを使ってアクセス解析もできます

ダッシュボードにて、アクセスランキング、逆アクセスランキングなんかも見ることができます

今後はアクセスに応じて調整するような機能などを追加していく予定です。

使用技術

作ってみた感想


ぜひ使って感想ください!

2017-01-28

http://anond.hatelabo.jp/20170128085025

理想を言えばmac,iphone, windows, androidを一通りそろえることだけど、

とりあえず始めるにあたってはいずれか一つあればいい。

サーバvpsを借りるか、自宅サーバ(linux)。独自ドメインもとってみると面白いと思う。

言語phpとかの方がいいんじゃね。javaめんどい



webサービスネタがないならはてブ(ソーシャルブックマーク)を作るのが王道

サーバサイドスクリプトDB基本的連携体験できる。

http://anond.hatelabo.jp/20170127120616

ブクマ含めて概ね「安すぎ」って意見だけど、それに疑問を感じてならない。トピ主擁護するわけじゃないけど、最低限だろこれ。

SOHOとかフリーランスならこれに基礎的なデザイン力と、コーディング力(HTML5+CSS3)と、最低限のコミュ力がないと10万すら稼げないぞ。

求人サイトのアフィ広告よろしく、わざと「PHPプログラマは月給50万円!100万円稼げる!」って言ってんじゃねーのか?現実は甘くないって。

2017-01-27

こういうWebプログラマって月20万くらい払えば来てくれるの?

要は「PHP+MySQL+JavaScriptで頼んだWebシステムを作ってくれる」人に来てほしい。会社地方単価で8掛けされる田舎にあるので地元求人見てるけど、月に15〜30万くらいの求人が多いし20万も払えば来てもらえるの?

2017-01-22

ownership とシステムプログラミングその他に関する怪文書

この会話ログフィクションであり、実在人物地名団体とは一切関係ありません。

坂木

わろた

Rust vs. Go に対する @tanakh さんの発言まとめ

https://togetter.com/li/1072495

坂木

自分理解できないもの意味がないと思いこみたがるタイプの人だということがよく分かったので原文を読まずに済んだ。ありがたいまとめだ。

安原

NTPsec が,ownership を理解していない開発者たちの声が大きくなるようなコミュニティによって開発されているということが分かって大変有意義でした(こなみかん

宮森

今までCで開発してきたプロジェクトを移すなら極端な話ownershipを理解しなくても良いわけで、悪くないのではと思う。

宮森

……が、理解できないものに対して、理解を試みず~すべきだ~と設計しろ、っちゅう人が作るソフトとはちょっと関わりたくないと思う。

安原

いや,私は C で開発してきたプロジェクトであるならばなおさら ownership を理解していないといけないと思います. ownership に理解を示さなコミュニティが関わってきた一定規模以上の C によるプロジェクト……私の第一感は「こわ…近寄らんとこ…」です.

宮森

いや、Cで開発してきた人たちって、ownershipを自前でコントロールできると思っている(思い込んでいる)人たちですんで……こわちかは同意

安原

いや,私は C で開発してきた人たちの多くは,そもそも ownership の概念を獲得していないのではないか危惧しています.元々,私はもっと楽観的で,多くの C プログラマは ownership の概念を獲得していると思っていました.

宮森

あ、それはそうだと思います概念を獲得していない

リソース人間管理をすれば適切に管理できる、という思想の下に皆さん書いていらっしゃるので……。

安原

OpenSSL騒動の時,関数の途中で return したことによるリソース漏れ揶揄したことがありますOpenSSL のようなインターネットの基盤を支えるオープンソースプロジェクトにおいてさえ, ownership の概念を獲得していれば脊髄反射で気づくであろうバグが随所に見られたことには本当に絶望しました.

安原

ああ,はい人間を信頼しすぎているというのはいかにもありそうですね.

藤堂

C++er の方がその辺もっときちんとしているように見える

安原

しろ C++ によって ownership という概念が明確になり,その重要性が認知されるようになったのではないでしょうか? これについては,私は歴史的なことが分からないので真偽のほどは何とも言えませんが.

宮森

シニア開発者しかC++/Rustが受けないと思うの、まさにその点だと思っていて、人類を信頼したがために足どころか頭を吹き飛ばす経験を積んでいないからだろうなー、とか。

宮森

OSとかシステム系のプログラマの人々、基本的リソース人間が適切に管理するし管理できると考えている人が多い印象([検閲削除]社時経験)。言語側で安全を確保したい、的な話をしても相容れなかった記憶が。

坂木

[検閲削除] のコードには、間違って自分の足どころか頭を撃ち抜いてしまった偉大な先人たちの知恵が詰まっていて、開発していてとても勉強になります。なお [検閲削除] は頭がなくなっていることに気づかずゾンビとして生きている模様。

今井

自分が知っている C 「しか」書けない職業プログラマ基本的地雷だなぁ...。

今井

リソースどうこう以前に、そもそもちゃんと構造化されてるコードが書けるかも怪しい(個人の感想です。見識にバイアスがかかっている可能性があります)

安原

うーん,数値計算系のチームやコミュニティも ownership の概念の獲得,重要性の理解,その管理自動化することへの理解,これらを期待するのは難しいだろうなあ…….そもそも高度なリソース管理必要になる場面少ないし…….

坂木

コード品質が強く求められるプロジェクトとそうでもないプロジェクトがあるからなあ。クライアントサイドソフトウェアは割と品質が求められる気がする。

安原

OS 実装とかシステムプログラミングって,クライアントに直接接しないだけで,その上にクライアントサイドソフトウェアが載るわけで,コード品質が強く求められると思うのですがそれは…….まあ, API とかで切り離されているので,そこだけしっかりしていれば,という話はあるか.

宮森

そこはコードレビューテスト等でカバーっちゅう。まぁ確かにコードには実際assertが入りまくったりするわけですが。

坂木

品質が強く求められるからといって品質が高いわけではないのが問題ですね

今井

あとは、デモが作れればいい、的なのも同じかなぁ。

宮森

メモリ管理、freeせずに終了してOSに全て回収させれば管理しなくて良い。

宮森

メモリ管理コンパイル時に全て静的なサイズで確保すれば管理しなくて良い。(FORTRAN77並の感想)

安原

OSGC してくれる論, TPO をわきまえているならば普通にありですよね(TPO をわきまえているならば!).

今井

まー、 offline で動くバッチ、的なのはそこまでメモリ管理とか / パフォーマンスとかにもシビアにならなくていいし(最悪オーダーがほどほどならよい、的な)、そいう文化にいると、雰囲気にのまれる人が多い、というのはまぁわかる。

坂木

私は基本その文化で過ごしてきたので現在進行形でわりかし困ってますね……

今井

あれ、そうなんです? 私がかかわった人のなかでは、コード見ててもむしろカッチリしてるほうだと思ってたのですが...。

(つまり、ここから坂木さんのハードルめっちゃ高いという帰結が...)

宮森

いろいろ言っていますがワタクシ、そういう管理必要プログラムは全く書けなくなりましたので今書くと死にますプログラム顧客大事データが)

安原

しかし,システムプログラミング界隈に「人間リソースを適切に管理できる」という悪しき信仰がはびこっているの,何か構造的な原因があったりするのかなあ?

宮森

システム系、基本的に生のハードウェアが透けて見える言語を使う必要があって、そのために選択肢がCしかなくて、手段が限られているからこそ信仰が発生した、という認識

宮森

実際、Linuxカーネルとか、規模からすれば驚異的に少ない数のバグで動いているので、信仰心が生まれ気持ちも分かる。

宮森

他の言語OS書くっていうのも研究レベルではあるけど、実用になっているのは見たこと無いですねぇ……。

坂木

Linux カーネル、一体どうやったらあの規模のコードクオリティコントロール出来るのか本当に不思議

安原

Linux カーネルのアレは,属人性依拠しすぎていて全然スケールしないのでは…….

坂木

Linux カーネル属人性高そうではあるけどそれでも実際に十分スケールしているからなあ…… ヤバいレビュアーごろごろしているのかな

宮森

属人性依拠しさえすればできるので十分な数の開発者がいれば問題になりません(キリッ

安原

私も [検閲削除] のコミュニティを見てましたから,各々必要ドメインにおける圧倒的なタレント性を持った人たちが1ヶ所に集結して奇跡アンサンブルを奏でうる場合がありうるのは理解しているんですが,本当にただの奇跡しかないと思っています

宮森

つーても機械エンジニアリング町工場職人芸を必要であれば使うように、属人性を求めるのも一個の正しい戦略だと思うんですよね。

宮森

なおその対極がみずh(省略されました

安原

Linux カーネルにおけるスケール云々は, Linux カーネルコミュニティ自体におけるスケーラビティではなくて,(システムプログラミングコミュニティ全体(他のプロジェクト)へスケールするかどうかを言ったつもりでした.

坂木

まあ人外を集めるという手法一般にはスケールしないですからね……

宮森

C系がシステム系で優先されるの、ツールを変えるとツール独特の罠があるので、罠が全て分かっているツールを使う、っつうのもあるな。

安原

システム系、基本的に生のハードウェアが透けて見える言語を使う必要があって、そのために選択肢がCしかなくて、手段が限られているからこそ信仰が発生した、という認識

これが原因だとすると,やはり Rust だ……Rust しかない…….ツール周りとか,まだまだ未整備な部分たくさんあるけれど……そこをクリアすれば…….

坂木

Rust は 1.0 が出る直前くらいにちょっと触ってイテレータが作れなくて敗北したっきりだな。

坂木

イテレータっていうか Java でいう Scanner を作ろうとしたんだっけ。サードパーティライブラリも探してみたけどその頃は I/O 周りの API が unstable でビルドが軒並み壊れていたりしたな……

藤堂

1.0 以前のことは忘れましょう (本当に unstable)

安原

Rust,型でエラーを弾くだけではなくて質の低いプログラマまでも弾く印象.

坂木

一般に型の強い言語は質の低いプログラマを弾きますね(Haskell などを思い浮かべながら)

安原

「Rust 経験者」という条件でプログラマ募集して,それで入ってきた人材に C を書かせればよいのでは!(ピコーン!

藤堂

犯罪ですよそれは

安原

はい

藤堂

haskell 経験者を集めて php 書かせようとした会社がどこかにあったような (ヘイトけがたまる)

安原

まさにそれをイメージしていました.

宮森

どういう顛末になったか詳しく知りたいw

藤堂

うーん、それ以降の話は知らず

今井

Rust そして誰もいなくなった、にならないかが一番心配だったりする

安原

それな

宮森

もしかして、NTPsecの人がRustでミニサーバーを起こすのにすら苦労していたの、普段からバグありのコード生産しているからなのでは、という気がしてきた……。

(この辺で一同寝落ち

2017-01-21

情報活用能力調査について

先日、高校生情報活用能力調査についての結果が発表された。

http://www.mext.go.jp/a_menu/shotou/zyouhou/detail/1381046.htm

その結果について、「高校生表計算ソフト苦手 情報活用調査 正答16%どまり」と見出しを付けて報じた記事がある。

記事の本文では「表計算ソフトを正しく使えるかをみる問題の正答率は16.3%。」と書かれていることから文部科学省報告書の32ページの表にある「不正請求」の「S25-02」の問題を指していることがわかる。この問題は「数年間の認知件数1件当たりの平均被害額を,表計算ソフトを用いて計算することができる。」かどうかを調査する問題である

この問題は、結果概要にも報告書の94ページにも公開されていて、単に表計算ソフトの使い方を調査しているものではないことがわかる。「2008 年から 2012 年まで の認知件数 1 件当たりの平均被害額を求める」ために、正しい計算式を考え、その式を表計算ソフト入力して求めるという一連の処理ができるかどうかを調査する問題である。単に平均を求める関数を使えるかどうかという問題ではない。

この問題について、文部科学省の結果概要では「5年間の認知件数1件当たりの平均被害額を,表計算ソフトを用いて計算する問題」と書いている。しかし、問題本質をとらえず「表計算ソフトを正しく使えるかをみる問題」としてしまっている。ミスリードだ。

高校情報科では、「文書作成プレゼンテーション表計算指導する教科」との誤った認識のまま授業が実施されている現状がある。(リンク先の35ページ(PDFファイルの5ページ目)参照)

https://www.google.co.jp/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&ved=0ahUKEwjpiv-BitHRAhUME7wKHdxMDLQQFggaMAA&url=https%3A%2F%2Fipsj.ixsq.nii.ac.jp%2Fej%2Findex.php%3Faction%3Dpages_view_main%26active_action%3Drepository_action_common_download%26item_id%3D144709%26item_no%3D1%26attribute_id%3D1%26file_no%3D1%26page_id%3D13%26block_id%3D8&usg=AFQjCNGk_y9QJn8Oq9xY2nFwrhWWwnZUgg&sig2=KsKirJMrLkfAbZqaTD_UWA

この誤った認識助長する見出しになってしまっている。記事見出しだけを見た人が、「表計算ソフト指導を強化しなければならない」と短絡的に考えることにつながり、オフィスソフト操作に終始している高校情報科の現状を認めることになってしまう。その結果として、報告書の76ページから77ページにかけて書かれているように、情報科を履修した生徒とまだ履修していない生徒との差が生じないのではないか。言い換えると、情報活用能力を育成できていない情報科の授業を認めてしまうのではないか。その観点からも、この記事問題である

このような記事掲載してしまうのは、情報活用能力について理解していると考えられない。また、高校生情報活用能力調査の結果として「複数情報がある多階層ウェブページから目的に応じて特定情報を見つけ出し,関連付けることに課題がある」という指摘が、新聞記者になっても身についていないと言わざるをえない。

2017-01-19

http://anond.hatelabo.jp/20170119210801

ネタか?

c++なんて低級だからいい腕もってると思われるだろう

最近rubyとかphpプログラマー気取ってるクズが多いから余計にそう思う業界多いだろ

2017-01-18

(A)isBigThan(B) のような関数はなぜ書けないの?

後ろにまとめて引数を書くのが普通だと思うけど(というかそういう形しか知らない)、

別に先頭や真ん中に引数受け口を作っても良いのでは?

自分JavaPHPしかしらないけど、その2つはそういう実装はできない。

正直値の比較なんて、どっちが基数かで結果が変わってくるし、文章っぽいほうが可読性も上がると思うんだけど。。。

バッチ書ける?」と聞かれて

バッチ処理のことしか思い浮かばなくて話がかみ合わなかったけど、よく聞いたらWindowsのBATのことだった。

バッチの貧弱な言語機能を補うべく、いろいろテクニックを駆使して分かりにくいコードを書かなければいけなかった。

バッチ以外の普通プログラミング言語で書いたほうが、メンテナンスとか楽だろうと思ったけど、こういう時に言語の変更を提案しても100%却下されるから、黙って仕事をした。

メンテするのは俺じゃないしな。

 

何年か前にも、Windowsサーバーで使うバッチを書かされたことがあったけど、そのときバッチでは実現できない機能実装しなくてはいけなくて、Cで外部コマンドを書いた。

そのサーバーにはperlインストールされていたから、これPerlで書いたほうがいいですよって提案したけど、分かる人がいなくてメンテできないからって却下だったな。

技巧をこらしたバッチ + Cで書かれた外部コマンドの処理も、そこの人たちにはメンテできないだろうからどっちでも同じだろうって内心思ったけど。

 

その現場の人たちもPHPを使ってるんだから、(シンプルな)Perlなら、見れば分かるだろって思うんだけど、まあ、技術に興味ない技術者の未知の技術への恐れはすごいから無理なんだろうな。

ログイン ユーザー登録
ようこそ ゲスト さん