「ライブラリ」を含む日記 RSS

はてなキーワード: ライブラリとは

2017-06-24

競技プログラミングをやってみた

これまで業務システムの開発をやってきて、自分一人でも

要件定義から開発、運用まで全部こなせていたか

それなりにプログラミングはできていると思っていたけど、

競技プログラミング全然違う分野なんだな。

業務システムでは言語仕様ライブラリの使い方を覚えて、

データの見せ方をどうするかを考えるのが重要だと思っていて、

アルゴリズムデータ構造よりも、DBテーブル設計

すっきりしていると、SQLだけできれいに取ってこれるから

これまで気にした事がなかった。

競技プログラミングは、学校で習ったプログラミングに似ている。

(まだ初級問題しかやってないからわからないけど)

現場で利用する言語ライブラリも一通り習得してしまったし、

システム構造もある程度決まってきて余裕が出てきたから、

しばらく競技プログラミングをやってみようと思う。

しかし、競技プログラミングの難しい問題を解くと、

転職オファーが来るらしいけど、こういうアルゴリズム

必要とする業界ってどういうとこなんだろう?

普通の人事、経理生産管理物流なんかのシステムしか知らないか

想像がつかないや。

プログラマー技術力とは

やっと理解したけど、出来るだけコードを書かないことなんだな

GitHubでいい感じのライブラリを見つけて、sqlマイグレーション

サーバーレスコンフィグ設定もせず ほぼせず

スケーラビティawsEC2クラウドフロント、S3使っていいかんじ

AIAPIでなんとか

シコシココード書くのは古くなった感じある

2017-06-23

コーディングコードレビューペアプロするより、優秀なプログラマーコード読んだほうが早くね?

下手な議論しても改善って割りとしないぞ

例えば新卒1年目と2年目がコードについて語り合ったところで、表層の話しかできないのは想像できるだろう

それよか世界大勢いるガチな人たちのコードを読んで、どうしてそうなってるのか考えたほうが有益

ガチな方々のコードはだいたい難しくて理解できないが、たまに発見がある

その発見を積み重ねていくだけでだいぶ違う

 

じゃあ何を読めばいいかって言ったら、公開されてるライブラリの中身を読むんだよ

誰もが知ってる有名なやつ

2017-06-15

エンジニアプログラマーだが、英語がつらい

英語がつらい。

やっぱり辛い。

たぶん幼稚園英語でなんかやってたみたい+中高6年間+浪人自体英語特訓+大学英語+趣味業務での英語学習.....ずっとやってきたけどつらい。

英語を読むのが辛い。俺は理系なんだが、文法問題とか、すごく得意で、毎回高得点を取れるので、英文法はできると思うんだが、単語が覚えられない。いや、中学高校単語帳に乗ってるようなものは覚えてるよ。けど、英語でさ、技術系の論文読むときに、わけわからない単語が出てくるんだわ。そのさ、その時に辞書引くじゃん? 今は、んでさ、調べている間に、読んでた内容がすっとんじゃうわけ。

もっとつらいのは、知ってる単語、その文の主語とか文法は分かるんだけど、その一文の意味がさっぱり分からない時があって、それもつらい。その時ってのは、その文自体が、なんか特別言い回しだったりするわけ。まんま、なんか流行ってる言い回しなら調べたら解決する場合があるから、良いけど、ちょっと捻ってるのわからない。どうすりゃいいんだ。

もっとつらいのは、英語の聞くときだ。本当にわからない。いろんな方法を試したんだけど、ほんとうにダメ。無理。ほら、TEDやら5分のニュースあるだろ?あれ、僕全然持たないんよ。その最初は、頭の中で、英語の文をつくる感じになるじゃん? そして、日本語にすんの。なんというか、英語の音=>英文=>日本文=>意味みたいな流れをずっとやってるわけじゃん? あれできるやつどうやってんの? 大分負荷が高いよね? 1分ぐらいで頭が沸騰するんだよ。

いや、もうだめ。英語。ほんとダメ。同僚はすごくできるのに。いくら日本語で書かれた難しい技術理解できたってダメだと思うんだけど、もうね、ダメだと思う。

「型システム入門」「分散システム」「On Lisp」「ガウディ本」「メイヤーオブジェクト指向入門本」....いろいろ日本語の本であるならば、全然読めるんだよ。けど、英語が読めねぇんだよ。

なんで、こんなに英語ダメダメでも、いろんなライブラリ使えてきたかって、実装を読めば分かるじゃん。英語ドキュメントは読めないけど、コードを読めば、どう動くか分かるじゃん。だから、なんとなってるけど、限界を感じてきたんだよ。なぜかって、仕様なのかバグなのか分からないんだよ.......だから英語仕様読むしかないんだけど.....本当につらい。

英語つらい.....英語つらい.....英語つらい.....

2017-06-14

Golang勉強3日目ぐらいで疑問に思っている事

これは将来Golangに慣れて来た頃に読み返すメモです

学習してから3日目ぐらいだけど連続3日でやったとは言っていない。

学習時間は24時間にも満たないと思う。

モチベーションが上がった時に学習する程度。

公式チュートリアルをやってるけどやった箇所は忘れた。

英語版日本語版があるけど日本語版情報が古くないか不安

まだ半分ぐらいしかやってないけど良チュートリアルだと思う。

他のプログラミング言語と違ってチュートリアルの内容が足りないってこともなさそうだし、Golangチュートリアルだけは繰り返しやったほうが良さそう。

からGolangを学ぶならGoogleリポジトリにあるパッケージ管理depを使うほうが安心する。

まだ公式ツールじゃないけど将来なるかもしれないしならないかもしれない。

Googleのことだからgxuiみたいに更新されなくなる危険もあるよな・・・

でもプロジェクト新規作成するときrails new helloに相当するコマンドがないので不便。

スケルトン生成ツールが別途必要だけどフォルダ作るだけだからbatファイル用意するだけで良さそう。

あとGOPATHの設定もか。今のところは手動でやってるけどそのうちbatファイルにしたい。

Golang自体シンプル言語だと思う。

でもやりたいことができないのがつらい。

Rubyみたいにcursesが標準で使えない。

RubyみたいにTKも標準で使えない。

cursesぐらいは標準で出来て欲しいよ。

から他の言語はいらないのにGolangではそんなことでもライブラリを探してきてインストールしないといけない。

開発環境にはGoglandかVimがいい。

Goglandだとそのままでも十分だけどVim場合vim-goを入れるのが良い。

勉強会に参加するときは軽量ノートを持っていくので動作が軽いVimがいい。

でもryzen搭載ノートが来たらIDEに乗り換えるかもしれない。

コマンドラインツールを作るならGolangが一番簡単

cliってライブラリもあるみたいだけど標準機能flagだけで十分便利。

学習3日目でもflagの使い方は楽勝だった。

今の所もあんまりコマンドラインツールに興味ないので難しいことはしない。

とりあえず2ちゃん質問するのが良さそうだけど過疎だった。

過疎ってことはあんまり人気がない?

まだ質問するぐらい基礎的なもの学習してないけど。

やりたいことをぐぐってコピペしてる程度なのでdeferとかgo funcとかグローバル変数とか基礎的な部分はまだ知らない。

インストールが楽だけどWindows作ったらMacでも動くかは謎。

Mac mini買ってから試したい。

でもMacって高いから多分買わないと思う。

MacハードウェアしかMacOSインストールできないライセンスからWindows PCMacインストールできないかapple嫌い。

初心者だけどMac持ってる奴apple信者キモ杉と言わせてくれ

2017-06-13

pipの気になるところ2つ

はてブロQiitaもやってないからここに書く

いつまで~も --process-dependency-links が DEPRECATION: will be removed in a future release.

表示されるようになって3年以上経ったぞ。

将来のリリースっていつだよ。

こういうことをするとオオカミ少年寓話みたいになるからリリース目途が立った時点で表示して、それでも目途がなくなったら一旦取り消せよ。

setup.py の dependency_links の扱い

以下は python setup.py install だとインストールできるが、 pip install . --process-dependency-links ではインストールできない。

dependency_links=[
    "git+https://github.com/requests/requests.git",
], 

一体なぜ?

結論から言うとpipはバージョン指定しないとdependency_linksを無視しやがるの。

dependency_links=[
    "git+https://github.com/requests/requests.git#egg=requests-2.17.3",
], 

issueによると、依存関係解決するまでライブラリ本体をフェッチしたくない(=URLバージョンが含まれていないとバージョンを知る術がない)んだそうで。

うん。気持ちはわかるぜ。

見つからないならフォールバックするくらいしてもいいと思うがな。

だが本当に気に食わなかったのはそこじゃない。

何より気に食わないのはdependency_linksを無視した時に何もログに残さないことだ。

警告すらない!

このせいで何分無駄にしたことか!

死ぬまでpipのメンテをしなければならない呪いをかけてやるぞ~後悔しろ

2017-06-03

http://anond.hatelabo.jp/20170602110049

便利なライブラリ群がなかったら人生懸ける覚悟でないと昭和レベルプログラムも書けないんだろうなとncursesを突付きながら思った。

2017-06-02

http://anond.hatelabo.jp/20170602110049

あなたがこだわっているのは、どう作るか?であって、

プログラミング本質は何を作るか?なんだよ。

何かを作りたい時にそれを素早く作れるように、

何年も掛けて世界中プログラマが地道にライブラリやAPIを整備してきたんだ。

それを一人で一から作るのは無理に決まってる。

結局プログラミングってライブラリってことで良いんでしょうか

自分プログラミングしてる感じしない

はいえ、じゃあお前が作ればいいとかいわれても作れる気がしない

なんていうか、全能感がない

正直これ俺のプログラムなの?ってかんじ。いえる自信がない

ライブラリライブラリライブラリ

とにかくライブラリ大事

あとAPI

APIAPIAPIAPI

結局プログラムってAPI操作することなのね

2017-05-28

プログラミング習得して就職しようとして諦めた

何のスキルもないニートの例に漏れず、プログラミングを覚えて就職しようとした。やっぱり諦めたけど。

はてブ見てると毎日のようにIT系記事トップに上がってくるから、なんか影響されてしまったんだろう。

Udacityというオンライン学習サイトがありまして、そこの”Intro to Computer Science"という無料コースちょっとやってみることにした。

これは初歩の初歩から始まって最終的にgoogle検索エンジンにも使われたアルゴリズムの簡易版を自分で作ろうって感じの内容で、「そもそもプログラミングって何?」みたいなところも説明してくれるのでとっても良かった。

ただ当たり前だけどその入門コース終わらせたところで「よし就職するぞ」みたいになるわけではなく。

「じゃあ次は」って思って何か作ろうとしても特に何も思い浮かばない。そういう目的プログラミング覚えようと思ったわけではないから。

試しに上のudacityのアンドロイドアプリ入門のコースもやったけど、だめ。チュートリアル的なものをこなしていくのは楽しいけど、自分で作るとなるとやっぱり何も思い浮かばない。

じゃあ人のソースコードとか見てみようと思っても、よくわかんない。何がわかんないって、モジューレだかライブラリかいうのを当たり前に使われててよくわからない。何が書いてるのか辿ってるうちによくわからなくなる。

このあたりで最初の入門コースをやっていたときの「『図にマッチ棒一本付け加えて三角形を○個にしてください』ってクイズみたいやな」って思ったときの関心みたいなのもなくなった。

それで気がついたら何もしてないままもう一年半ぐらい経ってたことに気がついてさっきびっくりした次第です。

そもそも本気でIT系就職しようと思うならハロワに行ってどっかおそらくIT派遣に飛び込んで実作業こなして覚えるのが正規ルートなので、結局上のはただの社会不安からの逃避ですね。

2017-05-07

http://anond.hatelabo.jp/20170507134627

Debugビルドにした上でDebug.WriteLine() あたりで。

というかNLogとかのロギングライブラリでも入れるべき

2017-05-06

Perlは終わった完全にオワコン

perlは終わった。もうずいぶん前から終わってたけど話題にも上がらないってことは完全に終わってる。

Githubトレンドを見てもperlなんて出てくる日の方が少ない。

結局Perlみたいにいろんな書き方ができるような言語はお呼びじゃねーってことだろう

Go/Pythonみたいな言語がもてはやされるのはそのためだろう

ライブラリ充実度に至ってはpython圧勝

Web開発ならRailsがあるRuby

どこでも動かせる意味ならGolangが最強だろう

Perl6については意味からない演算子増えて、さらに読みにくくなった

うPython, Rubyに追いつくこともできないだろう何よりリリースが遅すぎたもうPerlが入る余地はない

バイバイPerl(´;ω;`)ノシ

2017-05-03

新しい技術ライブラリ開発

先発組

・新しい技術が出てすぐにライブラリとして世に出てくる

・色々荒削り

ライブラリの中身は修正や改良を加えていくうちにごちゃごちゃに

後発組

・先発組のライブラリのいいとこ取りをしている

・先発組のライブラリで実現が難しかった痒いところに手が届く的なもの提供される

ライブラリの中身は設計が先にあるので比較的整っている

発明

勉強と称して既存ライブラリを使ったことない人らが作る

邪悪

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-04-22

http://anond.hatelabo.jp/20170422120647

笑わせんな。

元増田の書き方で

>~いいのにって思う。

実践はしていない)


の時点で相手にされねっての。

 人の作ったライブラリコーデックまで借りて「こうだったらいいのに」なんて人材要らねーから。(ってリーナスも言ってたw)

どうすれば使いやすくなるかを語りたかったらまず

日本語で書けるプログラム言語

 の話ではありませんって書いといたらどうなんだ?

そういう要点を得ない日本語力で他人の命名だけ批判して何もしてない連中だかその周辺に上から目線なんて言われるとマジであったまくんだよ。

C++/Perl/Rubyゴミ

分かったのは言語の多機能さというのは、一点水準さえ満たしていれば、それ以上足しても生産性寄与しないという事

自分しか使わない、最初書くときに限れば書きやすいと思うこともあるが、それ以上に保守性を落とす

ライブラリを利用したり他人コードを読む機会の方が多い昨今マイナス要素でしかない

perlスローガンだかに "There's More Than One Way To Do It." というのがあるらしいが、読む側からするとたまったもんじゃない

演算子オーバーロードされてるかも?モンキーパッチされてないかな?等々あれこれ想定しなきゃいけないのが苦痛しかない

スラムダンク流川が沢北を抜いたのも

パス選択肢を見せた事で沢北が集中できなくなってしまたか

それほど選択肢が多いということはストレスになる

Rubyゴミ

DSL(笑)が良いと思ってるのは最初だけで、最終的に負債しかならない糞コード

統計機械学習系のライブラリが皆無で先細りのイメージしかいかRailsと一緒に心中ください

Perlゴミ

リスト評価スカラー評価とか意味わかんねーくくりもtie変数アイディアは糞中の糞

Perl6にいたってはわけわかんねー演算子オンパレードで悪いところをさらに悪くした感じ

C++ゴミ

テンプレートマクロboostも何もかもダメ意味不明

オーバーロードされまくりコードなんてどっから読んでいいかわかんねーよ

こんな意味不明なことを覚えていられるほど人生長くない

結局PythonとかGo言語現実的な解で黒魔術のある言語なんて意味ない要らない使わない

2017-04-21

プログラム日本語で書けばいい気がするけど(追記した)

定期的に思うんだけどプログラムで無理な英語にせず日本語にすればいいのにって思う。

実践はしていない)

日本語で書ける言語使うんじゃなくて変数名や関数名がUnicode対応日本語書けるもの

日本語でいいと思う理由は主に2つ

○画面に表示する時

フレームワーク言語にもよるけど表示するとき英語名前から日本語名前に変換して表示って手間があるものがある。

最近見かけた例だと.NETプロパティ属性に表示名書いて表示するときに取り出していた。

最初から日本語だとそのまま表示でいいことが多くて一段手間が省ける

英語がわけわからん

まず自分英語化するとき

いい単語が出てこないとか、しょっちゅう

慣れが必要だし慣れてもなんかコレジャナイ感とかで苦戦する。

次に他の人の英語化したのを見る時。

その人の英語力にもよるけど、動詞名詞が変に混ざっていたり、sがついてたりなかったり、そもそもchildsみたいな謎の語があったり。

そこそこできる人同士でも、「私はニュアンス的にこっちの単語」「僕はこの単語のほうがいいと思う」とかある。

相手の書いたところがわかりづらいのはもちろんだけど、プログラム的に同じ意味なのにクラス関数によって呼び方違うと辛い。

かといって全員に日本語英語対応を先に渡しておいて統一しようというのは大変すぎる。

日本語だと仕様の時点で日本語で書いてるからまぁおかしなことにはそうならないはず)

そういうわけで日本語で書けば色々解決するのにって思う。

----

次にデメリット

軽く調べた感じ主にこの2つな感じ。

IME」「英語圏のものへの対応

IME

半角全角を打つのってめんどい

と思うけど、実際チャットやこういう文章書いてて英語が出るときに割りと頻繁に押してる。

ほぼ無意識でやってて意外と苦じゃない。

短いとF10変換で半角にすることもあるけど、キーボードタイプカウンタとか入れてみると半角全角キーはけっこう上位にいた。

それに、なんだかんだコメント日本語で書くことが多くて、他の人と作るのならこまめにコメント書いてる。

そうなると全角半角の切り替えは普段からあるもので、あんまり気にするほどじゃない気がした。

最近じゃIDEエディタの補完が優秀だし、日本語にするにしても「最初はjから始める」とかルール入れておけば「j」って打ってあとはスコープにあるいくつかの候補から選ぶだけで全角にしなくていいかもしれない。

英語圏への対応

githubで公開したりとかライブラリ再利用してもらうとき日本語じゃ使ってもらえない。ってことみたい。

私が日本語にすればいいじゃないって思ってるのは、ビジネスロジックというかそのアプリケーション固有名詞みたいなところ。

「足し算」って関数名は 「add」 でいいと思うし、配列のそれぞれは element とか item とかそういう一般的英単語でいいと思う。

具体例がいいづらいけど、業務システムで表示する金額名前とか、日本語独特なものとか、一般的単語じゃなさそうなの。

こういうのを日本語にしたいってわけなので、ライブラリ的な共通なところは英語で良いかgithubで公開する範囲英語のものでいいと思う。

ただ、最近はやってるマストドンとか、ライブラリ的なものじゃなくアプリケーション自体githubで公開する場合はできない気がする。

でも、海外対象にしてるものだと日本語特有なせいでわかりづらい英語になる苦労とか少なそうだしそういうのだと英語いいんじゃないかな。

----

長くなったけど、まとめると、

業務システム固有名詞とか日本語特有ものとか無理に英語化してよくわからないことになってり、見づらくなるくらいなら日本語使えばいいんじゃないかな

ということ。

まあ思ってる割には実践してないので、やってる人がいたら良かった・悪かったとか聞きたいなと思ったのが書いた理由

追記


帰ってきたらすごいブクマついてた。

色々意見あってとりあえず感謝

絶対自分でやってから言えよ」みたいな意見来るだろうと思って今日の空き時間日本語行ける言語調べたり軽く日本語使ってコード書いてみたので、そのあたりと目についたコメに答えてみる。

まず、思いの外日本プログラミング言語上げてる人がいたので、うまく伝わってなかったぽい。

具体例上げずにサッと書いたらからかな。

あと自分もわりとするけどタイトルだけ見て中身見ずにコメントしてた人もいるだろうなー。

日本語で書ける言語使うんじゃなくて変数名や関数名がUnicode対応日本語書けるもの

これが、などしこやひまわりや、BF系のmisaやら北斗のあれやらうにゃーとか色々な「構文など最初から日本語を前提とした言語」ではないってこと言ってた。

---

日本語かえる言語

最近の主要な言語ならだいたい Unicode 対応でしょと思って環境があった言語を試した結果はこうだった。

JavaScript/Python/PHP/Scala/Kotlin/C#/Go/Swift

これらは日本語変数作れた。

rust と Lua は無理だった。

rust は確か前に、変数名が ascii 文字だけなことに日本以外のどこかの国からUnicode対応にしてって多くの要望あったみたいな記事があったし将来的に対応するんじゃないかなって思ってる。

実際に今どんな状態かは知らない。

その記事コメントとかでみたけど、日本語以外は割りと自国言葉を使ってたりするっぽいね

(正確なデータはないか信憑性はあるとはいえないけど)

VBA を上げてる人がいたけど、私はそこまでのはみたことない。(幸せ者っぽいな)

稀にエクセルマクロいじるときに使い方ググってて出て来る、解説してるページで関数名が日本語なのをたまに見るくらい。

パット見なんか気持ち悪い感はあるけど、読んだときのわかりやすさはけっこう大きい。

---

○使ってみて

大規模案件に使ってみてこその問題もあるだろうけど、簡単スクリプト程度のを日本語にしてみて気づいたこと。

割といける。

全角半角キーPHP の $ より楽。

PHP言語変数は全部$からはじめないといけない欠陥言語

まあ変数のみのgrepのしやすさや予約語キーワード変数名に使えるからメリットもある。

だが、$って打ちづらい。

Shift+4ってすごいつらい。

に比べて全角半角キーってちょい遠いけどそこまで苦痛じゃない。

ふだんから多用してるキーなわけだし。

ただPHP日本語の組み合わせは相性悪い。

$は半角でその後に日本語から手間が多すぎる。

それ以外の言語だと、IMEのおかげでかなり楽。

GoogleIMEだけど、多少のタイプミスは補完で修正してくれるし、予測変換が優秀だし。

IDEいから補完機能のない軽いエディタで書くようなときなら、IMEのおかげで英語変数名で書くより速度は早いと思う。

---

少し前に知人から言われた日本語デメリットを思い出したのでそれも触れとく。

仕様変更言葉変わったとき日本語だと全部書き換えないといけないよ。英語だと別にそのままでいいし。」

英語からない人が、英語言葉とみなさずただの記号として考えてるから、っていうような発言

仕様変わって変数名まで変えるのは面倒なのはわかるけど、あとからコード読む人が英語で見て意味不明になる。

英語日本語対応コメントに書いたとしても、全然意味の違う英語があるのは混乱でしかない。

こういう考えの人がいたら本当にやめてほしい。

---

あとは気になったコメントについて書いてく。

表記ゆれとか方言とか言い回しなどについては、全部日本語にするとあるだろうけど、私が想定してるのは直感的に英語にならないような固有名詞とか。

DBの項目名日本語っていうのは私の思ってるのと近い。

年金の例も○○年金というのがいろいろあって、全部英語だと嫌になってくるしよくわかる。

こういうのを日本語にしたい。

なので年金額を取得する関数で「年金額を取得する」「年金額を取得」「年金額を取り出す」とかの表記を迷うんじゃなくて「get年金額」でいいと思う。

こういう単語だけだと表記はそれなりに揃うと思う。

特にDBにある項目だと仕様とかで先に言葉が決まってることが多いだろうし。

---

見た目について。

見た目が残念とか見づらいというのは同意

ただそれ以上に読んだときのわかりやすさが大きいと思う。

見た目が悪いというのも全部英語っていう前提があるからで1ヶ月も日本語コード見ればなれるんじゃない?って思う。

---

へとヘ

これはありそうな問題

ただ、IDEを使う前提なら未使用変数エラーとか、選択したときに色が変わってないとか、割と気づけると思う。

lとIとかアルファベットでもあるけど、IDEや高機能エディタ使うと困ることはほぼなくなった。

---

ローマ字

私が日本語にしたいような固有名詞ローマ字化してるプロジェクトにであったことはある。

やすい語は見やすいけど、見づらい語は圧倒的に見づらい。

それにローマ字のほうが「ん」でnは1つか2つかや、ヘボンorローマ?という日本語より表記が揃わない問題ある。

特にローマ字場合自分キーボードで打つ方じゃないと書きづらいのでそろえてもらうのに抵抗がある。

---

ラバゴス化・日本が遅れる

海外向けとか海外の人と一緒に作る系なものって最初から英語で困らない単語ばかりだと思う。

そういうのは対象外

今回いいたいのは、元から日本しか対応してないような業務システムなど。

そういったところの固有名詞日本語になったからって、困ることはないはず。

もともとガラバゴスなわけだし。

日本しか使われないもの海外向けにするにしてもフルスクラッチで作り直すことになるようなもの

こういうのは日本語化いいんじゃないかと思う。

---

テスト

テストだと日本語が使ってる人多いのかな?ブコメスタートップだし。

とりあえずはテストから使い始めてみようと思う。

---

長くなったけど参考になる意見もいろいろあって助かった。

単体テスト盲信してる皆様へ

そもそも意味あるのかちゃんと考えてる?

単体テストを書けばバグが減ります!」

単体テストのお陰で精神的安定を保てます!」

馬鹿じゃねーのかw?

テストコードメンテなんてデバッグの手順書メンテしてるのと大して変わらねーよw

その単体テストが本番と同一の動作テストできてる保証はねーって気づけボケ

本番と同じ動作テストたかったらデバッグしろ

なんで別のコード書き始めちゃうの?無駄じゃん馬鹿じゃん

それと「テストコードがあるから安全です」なんて寝言まだ言ってるの?

プロジェクトが進むにつれソース依存ライブラリも変化する以上

いつも同じ結果になるわけじゃねーだろが、(保守しないって選択はあるけど金入ってこないだろ)

本番でもテストコード動かしますってやつら以外無理して単体テスト書く必要ないんじゃねーか?

お前らが欲しいのは軽いデバッグモードであって単体テストじゃねーだろ?

工数削って単体テストを書いてソースが変わったらエラーになるからテスト書き直して・・・ってどう考えてもお前らが望む世界じゃないんじゃねーか?

流行りのTDDするくらいなら新人デバッグやらせた方がよっぽど筋がいい

というわけでよく考えなおせ

みんなが単体テスト言ってるから無理やり使うって運用やめろ

http://anond.hatelabo.jp/20170309040708

追記: 元ネタを茶化したジョークです

2017-04-19

http://anond.hatelabo.jp/20170416085444

他人ライブラリは嫌いなんだよね

jQueryってなんだよ、使いにくいよ

自分で作って自分で使うよ、という感じ

2017-04-16

http://anond.hatelabo.jp/20170415104722

JSが書きやすいって随分特殊な方だな...PHPやってる人間なら当然ながらJSも触ることになるけど、あれは他の言語比較しても特殊だと思う。

まあその深淵なる言語への理解が及ばないかjQueryとかのライブラリに逃げるわけだけど。

生のJSは難しい。

2017-04-15

http://anond.hatelabo.jp/20170415115330

結論から言うと型を欲するのは成長できた言語のみに許された特権である

どんな言語最初から厳密な型チェックをアピールしてしまうと開発を阻害するばかりで流行らない。

増田理屈だと最初から全部C++Javaで作ればいいじゃんとなるが、

現状を見るにそうはなってない。

web黎明期フロントエンドを支えたのは紛れもなく型チェックのゆるい言語だ。

パソコン黎明期一般向け主力言語BASIC(あるいはアセンブラ)だったわけだが、

時代が進むにつれて型チェックの厳しい言語を求めるようになるのは理由がある。

それはプログラムの規模だ。

言語が出た当初はライブラリも少なく、できることも少なかった。

時間が経過してライブラリノウハウが蓄積し、マシン性能向上も相まってできることが増えてくると

プログラムの規模も増えてくる。

すると、厳密な型チェックを取り入れないと全体を統制できなくなるのだ。

故に厳密な型チェックを取り入れるというのは、その言語(及び開発者)の成長と発展の証と言える。

2017-04-10

GENERATION AXE(4/7@Zepp Tokyo)に行ってきた。

高校時代青春ギター練習にささげ、ヤングギターを読んで教則ビデオを見ては「ああでもない、こうでもない」と試行錯誤に明け暮れる日々を送るギターヲタクだった現在40代の私にとって、

イングヴェイ・マルムスティーン

スティーヴ・ヴァイ

ヌーノ・ベッテンコート

ザック・ワイルド

この4名が一緒のステージに上がって演奏するというライヴ情報を見たときはまさに目を疑った。仮面ライダーで言えば初代とV3とストロンガーとスーパー1が一緒に登場して戦うような豪華さなである

タンディング席10,000円というチケット代に昨今の物価上昇の流れを感じながらも私は数ヶ月前からこのステージを心待ちにしつつ、ついに迎えた4/7、定時ダッシュの18:00で会社を上がり、そのまま一目散にお台場Zepp Tokyoへと足を運んだ。

これから綴るのはそんな私からの、ヒーローたちへの拙いラブレターである

1人目:トシン・アバシ

今回出演する5人の中では最も若く、当然私もインタビューで姿をチラッと見たことある程度の存在だったトシン・アバシ。当然音は一切聞いたことが無い。

8弦ギターを高く構えて演奏するスタイルを見て、「恐らくものすごいテクニカルで複雑な演奏をこなす人なんだろうな」と思っていた私の予想そのまんまの人だったので、何も新しい衝撃はなく、かと言って印象的なメロディがあるわけでもなく、ただただ早く終わってくれとしか思えなかった。

強いて言えば低音弦で鳴らすヘヴィコードがとても心地よく聞こえたくらいだろうか。

2人目:ヌーノ・ベッテンコート

アバシの黙々とした独演会ラスト曲で共演したヌーノ。曲が終わってアバシが去り、残ったヌーノはユーモアあるMCで客席を温めてそのまま「Get The Funk Out」を畳み掛けた瞬間からもう会場は雰囲気が一転!「そうそうこれが聞きたかったんだよ」というオッサンバサン大歓喜

EXTREMEの「Pornograffittiツアーからかれこれもう25年は使い続けているであろうギター、WashburnのN4。無塗装で手垢だらけのボディ、もはや何回交換したのだろうか分からないネックの先に伸びた印象的なリバースヘッド、そのギターを腰の位置まで低く構え、細く引き締まった体で長い髪を細かく振り乱しながら、リアピックアップL-500特有のトレブルな音を、爪を黒く塗った細長い指を駆使してカリカリと弾き出すそのヌーノのスタイルは、25年前から全く変わっておらず、我々ギターキッズにとって永遠の憧れであり、ヌーノといえばそのN4を携えたスタイルこそがアイコンなのである

ヌーノもおそらくファンのそういった思いをきちんと分かっているのであろう。ドラマゴッズの頃はほんの一時期だけ肥えていたこともあったが、昨今はさらなるワークアウトを続けてとても50歳とは思えない体型を維持している。

要は我々はそんなカッコいいヌーノが懐かしい曲を弾いてくれさえすれば良かったのだ。そしてそんな期待に100%応えてくれるかのように彼はEXTREME代表的ギターソロ部分をつなぎ合わせたメドレーで私を満足させてくれた。ありがとうヌーノ!

3人目:ザック・ワイルド

オジー・オズボーンの「no rest for the wicked」や「No More Tears」の頃は歴代オジーギタリストの流れを汲む印象的なリフとよく練られたギターソロで、私もよくコピーして練習していたザック・ワイルドの曲。

ソロ時代のザックといえば「Pride&Glory」こそが至高であり、その作曲センスギタープレイさらに輝きを増しているように私には見えたが、そこから何があったのだろうか、Black Label Societyなるバンドを組んでからというものの、知性がゼロギタープレイヤーに成り下がってしまった。

かつての「Miracle Man」のようなスピーディかつメロディアスギターソロ存在せず、適当チョーキングしている以外はペンタトニックスケールをフルピッキングしているだけ。ダサい、ダサすぎワロタ。ZZTOPを意識してるのか長いあごひげも汚いだけだし、時折モニタースピーカーの上に立ってゴリラモノマネをするのも「俺はこれだけアホになったぜ」と言っているようでかつてのザックを知る身としては寒くて痛々しくて仕方なかった。

彼に関してはとにかく「Pride&Glory」の頃のスタイルに戻って欲しいとしか言えない。よくあんな曲とスタイルレコード契約が持続できるなと思うほどのダメダメっぷりである

4人目:スティーヴ・ヴァイ

今回の5人のなかで誰が一番好き?と聞かれれば私は即座にスティーヴ・ヴァイと言う。中学3年生で「Passion And Wafare」を聞いて以来、未だに私のスマホ音楽ライブラリではこのアルバムヘヴィローテーションしているし、私が今メインで使っているギターIbanezのJEM7Vだ。

過去にヴァイ先生来日公演は見に行ったこともあるし、ライブ・アルバムライブDVDはすべてチェックしているうえに、YouTubeもかなりチェックしている。

したがってこれまでのGENERATION AXEツアーでどんな曲を演奏していたのかについては知っていたのだが、そのうえで今回はどう私たちを驚かせてくれるのだろうというのが一番の期待だった。

ザックに「エイリアン」と紹介され、のっけからヘヴィな「Bad Horsie」という意外な選曲だったのが嬉しかった。しかし、使われているのはあのミラーギター。全弦1音下げ+6弦ドロップCという変則チューニングのこの曲にあのミラーギターを使っているということは、すなわち今日は「Building The Church」をやらないという意味でもあったのだ。これはちょっと残念だったが、ひとまず「Bad Horsie」の重厚な音を堪能することにした。

その後は「Racing the World」が続いたが、今回の短い時間で聞きたいのはコレジャナイ感は否めなかった。アメリカツアーでは「Now We Run」もやってくれたそうだが、そういうのが聞きたかった。

そして「Tender Surrender」。ライブでこれほど映える曲はない。何百回と聞いている曲だが、それでも聞くたびにブルっとくるものがある。そこからは「Gravity Storm」もやったがこの選曲もやはりコレジャナイ感があった。

あともう1曲やってほしいというタイミングでヴァイ先生はあっさりとラストイングヴェイへとバトンタッチをした。最も思い入れのあるのがヴァイだっただけに、今回のセットリストちょっと残念だった。

5人目:イングヴェイ・マルムスティーン

実は私、生でイングヴェイライブを見るのは今回が初だった。ただ、古くはWOWOWライブ中継や、DVDYouTubeを通じてイングヴェイライブはさんざんチェックしているので、どんなライブをする人なのかはとてもよく知っている。

まさに「王者」の呼称にふさわしい、自信に満ちた堂々たる立ち居振る舞いで、とにかくピロピロピロピロと弾きまくり、3秒に1回はギター回しをし、5秒に1回はピックを投げ、10秒に1回は片足上げをするイングヴェイの変わらないスタイルが私は昔からずっと好きだった

冒頭から赤い照明にドライアイススモーク。そのスモークの中から登場するイングヴェイ。もう最高!

前半は知らない曲もあったが、中盤からは「イングヴェイといえばこれでしょ!」という曲ばかりでうれしかった。お決まりパガニーニからの「アダージョからの「Far Beyond The Sun」はもちろんのこと、なんと「Trilogy」も爆速演奏してくれた。

途中、例の「バディヌリ」を演るも、キーボードストリングスがまったく聞こえず、これでどうやって演奏を合わせるんだろうとそのあまりアンバランス具合に思わず笑ってしまった。また、片足上げキックの高さが以前よりも随分低くなってしまっていたが、53歳という年齢を考えればそれも致し方ないだろう。イングヴェイはこれでいいのだ(笑)

また、意外にうれしかった選曲オーケストラとの共演曲である「Fugue」。当然バックにテープを回してのイングヴェイ独演会ではあるが、ずっとバンドの音が続いてきたうえでこのようなサウンドは良いアクセントだった。

ラストはヴァイ先生との共演による「Black Star」!個人的にはこの曲が今回のピークだった。まさかギターハモリありの「Black Star」が生で聞ける日が来るなんて夢にも思っていなかったのし、その曲をヒーロー2名が一緒に演奏しているというのがもう感涙モノだった。

最後:5人揃って登場

さぁ最後5人揃って…のはずが、最初Frank Zappaの曲だろうか?知らない曲が始まり、弾いているギタリストイングヴェイを除く4人だけ。あれ?イングヴェイは?このまま出てこないの?と不安になったところで「Highway Star」が始まり、ここぞとばかりにイングヴェイ様が再降臨。もう本人も分かっているんだね。どういう音楽なら自分が一番かっこよく振る舞えるかってことが。

しかし、リードギタリストが5人も揃って一斉に音を出してしまうと、聞いている方は「うるさい」としか言いようがない。とてもじゃないがじっくりと演奏を聞くのは不可能で、ただあの5人が一緒のステージに立って演奏しているという感動を味わうのが精一杯である

かくして長い長い3時間半が終わり、会場を出たら時計は22:30前になっていた。足は棒のようになり、膝や腰にも痛みが来てしまったが、それでも私のギター人生において一生の思い出とも言える素晴らしいステージだった。この企画来日公演を実現させてくれた全ての人々に感謝をしたい。

2017-04-09

経済格差による情報格差の一例かな?がんばって。

長く書きますお金の話の経験とかも、少しでも参考にしてください。

話に一個ずつ答えてく

10年前のVistaが搭載されていた頃の家電量販店で一番安かったCeleron 1コア メモリ1GB グラボなしノートからプログラミングに向いてないのかもしれない

4年前になるけど、高校生の時は1万円くらいのパソコン中古で買って、使いにくいのを我慢してて、実際損だったなと思うこともある。

お金のない環境を整えられない学生はつらいよね。明らかに札束で殴れず時間を使って損してる。

twitterできないメインで使えないのもまず、重すぎるからっていうのもありそう。

スペックが足りてなさすぎる。まずは6,7万出してスペックを整えよう。

すごい人たちについて

すごい人たちは幼少の頃からパソコンがあって、パソコンをいじるだけの時間があって、承認されてる。

しかも、コミュ症だとかなんだかんだ言いながらも、ネットではきちんと弾けてるし、人望もある。

彼らを理解するのはすっごく難しい。

経済格差が多すぎて、彼らが積んできた経験と持っている環境が違いすぎるから

プログラム自体数学を解くようですごく楽しいのだけれど、なぜ苦しい勉強をしながらプログラムをずっとやっていられるのかわからない。

環境はMac(高すぎて揃えるなんてとんでもない)じゃないから、先人たちの簡単に手順化された知恵を受けづらく、プログラム環境をととえるまでが大変だし、

ライブラリ関係エラーコード自分の力で、ライブラリを見つけに行かないとダメで、ウェブ検索しても彼らよりもずっと時間がかかる。

そこをきちんと理解したうえで、自分がどこまでやりたいのか、どうしてやりたいのか

自分プログラマに向いているのか、考えながら、勉強していったほうが良い。

私について

ちなみに私はプログラムを解くの好きだったし、ある程度は得意だった。

ADHD自閉症混じってるから、だから職人的なことをやりたかったし、テストをかけば不注意で大きな損失を出す可能性も低くなる。

からプログラマを目指しているし、プログラマとして就職するつもりなんだよね。

twitterで有名な人てやっぱりSランクとか余裕なのかな

プログラマレベル

私も無名で、プログラム力的にはpaizaのSランクは、後ちょっと足りない、運が良ければ成功するんじゃない?ってレベル

イッタランドのすごい人たちは目指すと疲れるだけなのでほどほどにね。

彼らは多分余裕綽々でS取れる。

paizaの出題は競技プログラムの一種で、競技プログラムっていうのはある程度出題の仕方が似通ってる。

複数回解いていると昔に残ったコードとか再利用できたりするから有利になるっていうのもある。

ゲームで例えるとRPG好きな奴にFPSやらせても全く活躍できないけど、FPSが得意な奴に別のFPSゲーやらせてもできたりするでしょ。

開発のジャンルの違いがあることは覚えといて。

VirtualBox上のubuntuMySQLコンパイルすると2時間20分ぐらいかかった記憶がある。

開発環境OSについて

Mac買えなくて開発環境として選ぶなら,windowsよりlinuxのほうが良い。

windowsだと環境整える前にストレスやばいし、パソコンが死んだ場合ストレスやばい

あと、古いパソコンだとUSBブートができなかったのも割とめんどくさかったし、回線がめちゃくちゃ低速だったから、ISOファイルダウンロードに半日かかってたかな。

ubuntuは良いんだけど、スペック足りてない。

VirtualBoxはすごいスペック持っている人が使うものなので、買い換えないならクリーンインストールデュアルブート推奨。

ubuntuにしとけば、ウイルス系もあんまり構う必要性がなくなるからね。

フリーソフト選択肢は狭まるけど。)

起動にVirtualBox起動に数分待って、端末以外を使おうとすると固まるみたいなことやってると辛さが溜まるから

あとデュアルブートはいいよ

あと、クレジットカード持てないのでAWS上で機械学習するのだけは遠慮したい。

クレジットカードについて

デビットカードでも行ける。

するが銀行に口座を作ってデビットカードを申しこめば、20歳以下でもなんとかなる。(年齢によっては親の同意は必要だけど)

2,3週間かかるけど、デビットカード作っておくことで色々なサービスを体験できるようになるのは選択肢を増やすにあたって重要なことだから是非。

コンビニからお金を入れられるので地方でも安心だしね。


一応著名なプログラマーTwitterフォローしてるけど、ご飯の画像を載せてたり、若者の僕には通じない寒いギャク連発してたり、ロリっぽい画像をRTしてたりと、twitterはメインの情報収集としては利用してない。

SNSについて

ネット上は怖い人もたくさんいるし、まさかりがちょくちょく飛んでくるけど、変にウケる拡散してくれて色々な人が声をかけてくれるのも確かだったりする。

ゆっくり自分の使い方を覚えていけば少しずつ楽しめると思う。

実際、SNSは情報の精度としては当てにならないし、勉強のためってSNSを使うとストレスで辛くなった。

自分好きな人だけをフォローすると精神安定するよ、あとフォロー返しはやる必要はない。やってるとTL荒れるからね。

リストとか使いこなせるなら別なんだろうけどね)

ちなみにここに飛んできた理由ツイッターかな。







何を改善したら昔よりも良くなったかってことだけつらつらと書いていく。


おすすめ度は◎○△であらわす。

ノートパソコンを新調する
おすすめ度:◎
条件:最低で6,7万円のお金必要おすすめlenovoのeシリーズ。
重いけど、コスパは良好比較的安めに上がってキーボードも打ちやすいのが良い。
いまはcorei5, メモリ8GBの使ってて、大体(重めのゲーム以外)したいことはなんとかなる。
SSDはあったら便利だけど、一番重要なのはメモリな。
開発したいなら8GBは必須。
(苦労話:
古すぎてノートなのにキーボード常時接続必要だったり、画像が多いサイトブラウザを選ぶ必要があったり、何よりもIDEが使えなくて辛かった。
windows vistaのupdateで数日固まったりゴミしかなかった。
)

光回線契約にする。
おすすめ度:◎
条件:契約できる年齢か、親の同意(年4万円くらいの出費)が必要
何をするにもまず回線速度が遅いと話にならない。
IDE落としたり、クラウドファイル上げたり、AWS使う時のアップロードとか、音声会話とか。
〇〇をしてみたいと思ったら,ダウンロード時間がかからないことは、モチベーションのためにめちゃくちゃ大切。

(苦労話:
ISOファイルダウンロードするのに半日かかるのが普通だと思ってたけど、
まともな光回線+まともなルータを利用したら、ダウンロードに1時間ちょいになってびっくりした。
特に古いルータだったりするとボルトネックになったりする。
)

ubuntuクリーンインストールする。
おすすめ度:○
条件:linuxで生きていくという覚悟
windowsよりは快適。
他のlinuxISOファイルを焼いたりするときちょっと苦労するかもしれないし、軽いの選ぶと良いかも。
実際普段使うものネットプログラムツールだけだったから、なんとかなったし、ゲーム選択肢強制的排除されるので、
少しはプログラムに触りやすくなるかもしれない。
(苦労話:
エクセルパワポ必要とか言われた時に、officeレイアウトで死んだりする。
資料はPDFな。

買い換えない場合クリーンインストールは↓
昔のパソコンでもLinuxとか入れればそれなりに動くよっていう人はいるけど、やっぱり社会的通信網と平均的なマシンスペックが上がっているせいで、ウェブ自体要求するスペックも上がってて低スペックだとつらい。
ブラウザはw3mとか使って、端末タブを開いてvimで開発してた。
なんでかって言うと普通にブラウザ使うとレスポンスが重すぎたから。
でもその使いづらさの分だけ損してるんだよね。
)

勉強会に行く、もしくはライブ中継を見る
おすすめ度:○
条件:電車代などの交通費を用意可能
できること:
他人に触発されるタイプなら、すごい人たちの興味の方向を見て学ぶ方向が増えるかもしれない。
後は交通費宿泊費の出る勉強会なんてものもあるので応募してみると良いかもしれない。
高校生なら、交通費出してくれるっていう太っ腹な勉強会もちらほらある。
一、二回は顔出し推奨。
欠点はあって、コミュ症は治らないので、友達ができるとは限らない。


パソコンを触れる時間を増やす
おすすめ度:△
条件:家庭環境による
できること:
自分向上心による。
大学生になって一人暮らしになったら、パソコンに触れる時間は多くなったとは思う。
(勉強しているとは言っていない)


デスク椅子の購入
おすすめ度:○
条件:3,4万円の出費
できること:
まず、パソコンを長時間触っていても疲れなくなる。
デスクの高さと椅子の高さはとても大切なもの。
疲れなくなるし、指が攣りそうになることもない。
机の高さはきちんと調べたほうが良い、あってることが重要
今使っているのは1万ちょいの新品デスクニッセンフリーテーブル)と3万弱の中古オフィスチェア
基本的に3000円位のデスク耐久性と高さがゴミだったりするので注意。
机は http://blog.livedoor.jp/itsoku/archives/38727329.html の66のテンプレを見ておくと良いかな。
(苦労話:
しかノートパソコンデスク椅子がなくて狭いこたつの上か100均で買ってきた台の上で、パソコンを使っていたかパソコン位置の高さが合わなくて姿勢がどうしても悪くなるせいで長時間パソコンをいじることもできなかった。

後は寝ながらパソコンをいじるみたいなみたいな堕落生活してたら、筋肉が硬直してまともに手を握れなくなって、医者にかかることになって1万円程度お金がかかったし、
2ヶ月位まともにパソコン触れなくなった。
ちょうどその時期は、筆記用具をほとんど使わない単位だけだったから良かったものの、他の単位とってたらもっと治療時間がかかったかもね。
)



jetbrainsのIDEの使用
おすすめ度:○
条件:それなりのスペックパソコン、それなり大きさのディスプレイ
できること:
設定しなくても、複数ファイルから補完が聞くし、フォルダ内の全てのファイルから検索、置換ができるのが良い。
ただし、ディスプレイが小さいと実際に開発できる範囲が小さくなるのは注意。
(苦労話:
IDEは普通に使えるなら作業効率が全く違って、設定少なくても補完も他のファイルライブラリから保管してくれるたりする。
でも、昔の環境だとeclipseフリーソフトだけど環境整えるまでが辛いし、重いしで、開くとブラウザすらまともに操作できなくのが辛い。
だからブラウザチュートリアルとか見ててもパソコンに待たされてストレスだった。
まともに使うには設定がめちゃくちゃ必要なのは実際疲れた。

(ac.jpメールアドレス必要だけど)学生無料なIDEでjetbrains製品があるけど、設定しなきゃダメなvimとかと違ってマウス操作できるのがすごい良い。
端末ではコピペ簡単にできなくて、数は少ないけどよくあるミスが、間違えてcommandモードで貼り付けてやり直したり、vimのline numberの設定をいじらずにvimからコピペができる。
コレだけでイライラ具合が全然変わる。
)

図書館からコーディングの本を借りてきて読む(できれば、実践すること)
おすすめ度:◎
条件:図書館や図書室で本を注文できるか、本があるか
できること:
プログラム能力が向上する。
おすすめされている本を探すと良い。
プログラム学者なら、ネットだけで勉強するよりは効率がある。
とりあえず、やりたいことなくて、プログラム力をただ上げておきたい場合は、
競技プログラムやりたいとしても下の順番で進めると良いかもしれない。
あと、プログラムには自分が到達しているところまでで言うと、次の順で壁があって能力が足りないと行き詰まることがある。
>> 関数化 → クラス化 (→ ポインター) → 再帰 → 関数型言語 <<
数年かけて勉強して次の段階に勧めないならプログラマは諦めたほうが良いかもしれない。
(能力が足りないのは上司自分もつらくなるよ)


パソコンディスプレイを買うこと
おすすめ度:○
条件:1万円弱のお金
できること:
ノートパソコンなら2個の画面を使えると作業効率が違う。
特に手打ち系のコーディング練習とかがめちゃくちゃ捗るようになる。
(苦労話:
IDE系列は画面を割と占拠するので、ノートパソコンの狭い画面だと辛い。
でも大きすぎる画面だと持ち運べなくなるのでダメ画素数が上がればその分だけ小さく表現ができるので、画面サイズが同じでも画素数が違うとかなり大きさが違って見えたりする。
)

大学に入って時間を稼ぐ
おすすめ度:○
条件:学力があること努力すること、覚悟
できること:
奨学金を利用して環境を整えたり、時間が増えるから更に勉強できる。
プログラム関係もそれ以外も就職先が増える。
また、これから転職したくなった時に逃げ道が増える。
欠点国立は安いけど、入学にそれ相応の努力必要私立行けるなら、苦労してないと思う。
あと免除制度っていうのがあるから、そういうのも利用しつつ費用を安く上げよう

デビットカードを持つこと
おすすめ度:○
条件:年齢(か、親の同意)
できること:
ちょっとした電子払いができるようになる。
多重債務は起こらない。
欠点としては、定期払いはできないので携帯の契約とかはできないことに注意。




終わりに

スペックパソコンしか無いのは、多分家庭環境のせいでもあって、

君がアルバイトもできるかどうかわからないし、アルバイトしてもそのお金が君のもとに入ってくるかはわからない。

お金無限にあるわけじゃないし、時には経済格差を感じて辛くなることもあるだろう。

少ないお金の中でうまくやりくりして、それでも自分の力にしていってほしい。

お金が潤沢にあるなら親を説き伏せることをがんばって)

応援してるよ。

http://anond.hatelabo.jp/20170407112743

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