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

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

2018-10-15

求職

スキル

HTML/CSS/JavaScriptがかけます

ReactとVueが使えます

個人アプリ開発ができます

JavaScriptライブラリを作ってNPMで公開しています結構ダウンロードされています(週に数万回)。

データベースMySQLとIndexedDBが使えます

Firebaseも経験があります

言語

英語、少しできます

希望年収・勤務地

500万円以上がいいです。

東京都内がいいです。

2018-10-14

anond:20181014212324

フレームワークを使うし、標準ライブラリクラスで作られてるからクラス使わないでコード書くのは無理だけど、新規クラスとか作るとすごい感情的に怒り出すね。

フレームワークで使うモデルクラスなかにメソッドを作りまくって、クラスのなかて手続き型のコードを書いてる。

anond:20181014012351

たぶん「ゲームを作りたい欲」からの行動でなく「知識欲」からの行動なのかな?

ゲームを作りたいならunityUE4になると思うけど、知識欲の方が大きいのならば何学んでもいいと思いました。パソコン根本的なところから学びたいならアセンブリ言語C言語バランス取りたいならpythonとか、業界標準を学びたいならjavac#なんでしょうか。まあ結局知識欲が満たされればいいだけなら、どれかに絞るのでなく、どれもちょびちょびやってけばいいと思います

unityue4を使わないクソゲーなら「DXライブラリ」「cocos 2d」がよく挙がる気がしますね。そういうライブラリ使いたくないならprocessingとか

2018-10-13

anond:20181013204433

検定はわからないけどそれなりに使われてるOSSライブラリを作ってたりって感じじゃないか

ふと昔を思い出して

今は全然関係ないことに従事していて、それが大して面白くもないのだが。

たまにはラズベリーパイを弄ったり組版ソフト面白ものを見つけて弄っている。

そんな私が何年か前に30日でできるOS本とDIrectX9入門の本を買って触っていた。昔話だ。

こういうのは、いわゆる御呪いオンパレードだ。

Cを最初にやるときののヘッダーファイル、あるいはwindowsプログラミングウィンドウを表示するときの様な「おまじない」だ。

ロクな説明もされないまま、写経しているうちにコードが増えて行き、なんかサンプルに毛が生えた様なものができて満足するが釈然としない。

分かった気がしない。

OpenGL/GLUTを後年マニュアルを参照しながら一生懸命やったときの方が理解できた気がしたし、オリジナリティのあるコードとなった。

やはりこういう根幹部分の知識悪戦苦闘しなければ、身につけないのだろうかと少し思う。

昨今大量に溢れるラッパーやフックを見て様々な機能が便利になったと感心する。

プログラマとして働いたことはないが、車輪の再発明学習以外においては悪だと学んできたので、それは大変結構だと思う。

ライブラリ再利用は良い。だが、その便利さがかえって学習者の成長を妨げるのではないか

OS本やDirectXを訳も分からず触っていた私の様なコピペキディ(又は写経坊主)が増えないことを願う。

(もう少し時間があれば、pychamかnvimのhaskell pluginが書きたい。)

2018-10-11

internet archive books で英訳された漫画が読めるんですが

internetarchivebooksで、日本画での波の描写をまとめた本がダウンロードできるとハテブで上がってきてて、自分が好きなアルフォンス・ミュシャがないか探そうと、muchaで検索をかけたんです。

結果を見ていると、ミュシャ動画サムネが1件。

後はよくわからんと思っていたところ、muchakuchadaisukiというタイトルで、英訳された漫画がまるっと一冊。2巻以降もある様で。

サムネの左上にカーソルを持っていくと、マンガライブラリというグループが出てきます。そこを選ぶとずらっと出てくる漫画といくつかのラノベエロなのかぼかしが入っている物もあります

投稿2013年かららしく、アイテム数はもうすぐ2万件。閲覧数は昨年末から急激に数を増やし、累計300万を超えています

カリフォルニアフィリピンインドネシアコスタリカアクセス数の多いリージョンが表示されているのは面白いです。

また、今回の投稿者のリストを見ると、大量の資料の中にいくつものゲームソフトメディア雑誌などもありまして、

これをもとに広告付きのサイトも作れることを考えると、早いとこどうにかしてほしいものです。

もっともこれでも氷山の一角で、ほかに大量にあるように思いますし、そもそもアーカイブとして集めることが目的なら、公開の前にしっかり著作権確認しているのでしょうか。

アーケードゲーム等の公開も以前からされていて、問題があるのではないか懸念を持たれているようですし。

ひとまず今回の漫画出版社メールを入れました。許可を出されているなら、空回りで済むんですが。

2018-10-07

anond:20181007020821

https://news.yahoo.co.jp/byline/shinoharashuji/20181006-00099578/

マイクロソフト10月2日(現地時間から配信した「Windows 10 October 2018 Update」において、インストール中にユーザーファイル勝手に削除されてしま不具合が一部で確認され、問題となっています

 不具合の例は海外掲示板Reddit』を中心に報告されており、ユーザーフォルダ内のパブリックフォルダや「マイミュージック」や「マイビデオ」といったライブラリフォルダに保存していたファイルアップデート後に削除されてしまうというものです。

 現状は削除されてしまったファイルは、ユーザー個人バックアップをとっていない限り復旧できないとみられています

怖すぎるやろw

2018-10-06

エンジニアは「分からんことを人に聞く」という習性が無い

たとえば自分らのプロダクトで使っているライブラリで分からない点があるとする

レベル1の人は、文字通り全く無い。全てを自分解決しようとして、当然できないので爆発四散して死ぬ

レベル5ぐらいの人は、社内の人に聞くことはできるが外部の人間に尋ねることができない。爆発四散して死ぬ

俺は自分分からん・社内でも解決できないことはさっさとgithubでそのライブラリの作者に聞く

2018-09-29

誰もが簡単に「エンジニア」を名乗れる時代

いろんなツールフレームワークが充実してきて、少しググっただけである程度のアプリが作れてしまう。

インフラAWS簡単に作れるし、機械学習だってPythonライブラリで少し調べれば誰でも使えるようになった。

こんな時代エンジニア価値ってなんだろう?

2018-09-25

いつかの社内勉強会ネタに使えるかもしれないので記録。

ContainerPatternで"Ambassador Pattern"(Googleで直訳すると、大使紋章..めっちゃかっこいい)というのがある。

https://docs.microsoft.com/en-us/azure/architecture/patterns/ambassador

なにが大使やねんというと、サービスAがサービスBに接続するときサービスA'がサービスAの代わりにしてくれるかららしい。外交官的な。

接続にかかわるもろもろ、回線監視だとかリトライ処理だとか認証だとかそもそも接続する設定値だとかそういったものを代わりにやってくれるサービスを別途にもうけようぜという仕組みだそうだ。

その仕組みがはまる例として

・異なるプログラミング言語だとかフレームワークサービスを織り交ぜている

アプリ開発者が認証の仕組みまで意識して作りたくないよ

という時だそうだ。

ふむふむとうなづきつつ、アンチパターンの方で躓いた。

つのプログラミング言語しか使ってない場合メリットからクライアントに直接通信用のライブラリ入れろよというのは納得...したんだが、

Consider the possible impact of including generalized features in the proxy.

For example, the ambassador could handle retries, but that might not be safe unless all operations are idempotent.

一般的機能プロキシに含める影響を考慮してください。例えば、リトライ処理をするとき、全ての処理(注釈: アンバサダーリモートサービスに対する処理)が"冪等"でなければ安全ではないかもしれません。

冪等ってなに?え、リトライ処理でデメリットが生じることがあるの?(ログイン試行回数とか?)

有識者的にはあーっ知ってるよで終わる話(隣の技術者に聞いた感じ)なのかもしれないけどそもそもidempotentの訳を知らなかったので

ググると、"treasure data"の中の人ブログにたどり着いた。

リトライと冪等性のデザインパターン

これだよ!!これが俺が知りたかたことなんだ。ありがてぇありがてぇ。

接続しようとしている外部リモートサービスの話で合って、リトライする側のアンバサダーサービスが考える話ではないし、

接続しようとしているサービスに応じてアーキテクチャ設計が変わっちゃうと本末転倒感あるけど、

少なくとも考慮すべきポイントであることは了解だ。

...はぁ、勉強したー!!

2018-09-24

anond:20180924095349

現場10年頑張ってる人には敵わないかな。C・C++JavaPHPPython趣味程度に勉強してきた。知り合いに技術者がいるならその人に頼ったほうが俺に聞くよりいいと思う。聞く人がいないなら学校行くか良書を探す方法があるね。プログラミングを実際おこなっている動画を見るのもありだな。大工が家を建てるのと同じで本見ただけじゃ分かり難いとこがある。

上には書いてないけど金があるなら本を買うのが大事、優れた良書は家庭教師と同じくらい役に立つ。あと1500円くらいのその言語関数の一覧が分かる本。その2冊くらいは最低必要言語自体流行り廃りや潜在的な使いやすさもあるけど、ライブラリ解説書が揃っていることも重要最後に迷ったら言語使用人数が多い言語を選ぶという手もある。分からなくなった時にWeb関数名や用途検索すれば大体の場合検索に引っかかる。例えばこんな感じ「Ruby 配列 追加」「HSP 円」マイナー言語だとこれに引っかからない場合がある。

2018-09-22

JWTに関してのお伺い

http://b.hatena.ne.jp/entry/s/co3k.org/blog/why-do-you-use-jwt-for-session

適当コメントを書いたら

スーパーエンジニアに「そういうことではない」

と厳しい叱責を受けたため、無能の見識を書いてみた。

「聞くは一時の恥、聞かぬは一生の恥」のとおり、

せっかくの機会のため、びしばしセキュリティに関する認識の甘さを指摘してほしい所存

expの期限と任意セッションが切れないデメリットに対する私見

作ったシステムではexpは約1時間でやってしまいました(機密保持契約違反を恐れ多少ぼかしております)

私は無能なのでたぶんユーザーから報告を受けて

確認している間に1時間はかかるからいいやと思ってしまっていた

師はきっとJWT生成直後3秒でユーザー

「これは、セッションハイジャックか・・・!?

と気づいて通報

そして師が2秒で

「これは、セッションハイジャックだ!」

と検知してセッション遮断、秒速で一億円の被害が出るところを阻止する前提なのではないかと推測している

これは確かにJWTだと厳しそうだ

そもそもログインできるアプリなら

セッションハイジャック成功直後にパスワードを変更された場合

セッション任意に切れることに意味はないのでは、と思えてきたが、浅はかだろうか

(師はログインを即座に検知してセッションを切れるから問題ないのか)

とにかくアカウントロック機能を作れば上記懸念全てにきれい対応できそうに見えている

「定期的な鍵交換が必要」に関する私見

この理屈だと例えば.envに書くような他のkeyも定期的な交換が必要に見える

これはまずい、自分の今までの見識の甘さを思い知らされた

今使っているフレームワークリファレンスを見たが

keyは初回に設定したのみで、定期的な交換を勧める文が見つからない

私の検索力不足なのかと思ったが、もしかして彼らもこの危険性に気付いていないのではないか

JWTはhash化してつないでいる前提で

hashのkeyを総当たりで破る仮定で書く

私は無能なのでライブラリを用いることにしている

32文字keyが生成された

解読時間は下記を参考に、計算windows10電卓アプリを用いて手動で行った

https://ja.wikipedia.org/wiki/%E7%B7%8F%E5%BD%93%E3%81%9F%E3%82%8A%E6%94%BB%E6%92%83

数字大文字文字で約60の時は10桁で20万年と書いているが

現代の解析技術20万倍は速度が出ると仮定して1年として計算する

果たして、どのくらいの速度で鍵はやぶられると推定されるのか

とりあえず60を10乗した時点で(20文字相当)

6.0466176e+17

日本語に直すと60京4661兆7600億年かかる計算となった

実際にはこれが6.0466176e+17倍されさらに3600倍されつまりどういうことだ

これだけ長くともkeyの交換は必要なのであろうか

そもそも師は何年で交換したら安全と書いていないが、何年なら安全という意見だったのだろうか

「JWTはセッションIDを含めれば安全」に関する私見

から「そういうことではない」と指摘された点である

私の理解ではとかくuser_idのみ必要なら意味がないと思っていたため落ち込んでいる

まず、IDとpassを内蔵するネイティブアプリに対するapiサーバでの実装経験しかないこと

JWTが切れたら都度IDとpassを投げる方向でリフレッシュトークン実装しなかったことを告白しておく

そのためapiサーバ上記前提で用いた場合に考えたことを書く

webアプリのJWT実装経験はないので、そちらの論は差し控えさせていただく

JWT送信→user_id取得

では危険

JWT送信セッション(cookie形式?)送信切り替え→セッションからuser_id取得

だと安全になるのか検討する前提で記載する

とりあえず思いついたのは下記だった

通信途中で傍受されてログイン情報が奪われる危険が上がる
アプリから直接ログイン情報が奪われる危険が上がる

通信途中で傍受される危険に関して

tokenはheaderにbearerで付けユーザーID(あるいはそれに代わる特定可能識別子)が含まれ

おそらく一般構成仮定で書く

https通信するのでパケットキャプチャによる傍受は不可能と思っていた

(http通信するのはJWTとかcookieとか関係なく傍受できるため考慮しない)

0に何をかけても0なので、何回送っても解読されないならJWTを何回送っても問題ない

というかJWTが抜けるなら同様にheaderに付けるcookieでも抜けると思うので

JWTだからといって危険性に差はない、という論拠により安全性は変わらないという個人的結論になった

※余談だが、たまに送る回数が少ない方が安全という

言説を見るのだが、個人的には上記理由で納得できていない

アプリから情報が抜かれる危険性に関して

クライアントネイティブアプリ場合

攻撃者がアプリに保存されたJWTが取得できるならIDもpassも同じ方法で抜けそうに見えた

(厳密には保存場所が違ったかもしれんが実装依存なので同一とする)

その前提のため、わざわざ

JWT送信セッション(cookie形式?)送信セッションからuser_id取得 

接続しても、おそらくcookie形式で送れる何かもJWTらと同じ方法で抜かれると思われる

まりcookieだろうがJWTだろうがアプリから直接情報が抜かれる危険性には変わりがないという結論になった

結論

まりcookieだろうがjwtだろうがidpasswordの組だろうが同じ危険性で抜かれる可能性があり、いずれでも同じことができるなら

JWT→user_id

でいいじゃん、わざわざcookieと同様の形式を間に挟むの無駄じゃん、となりコメント発言に至った

ここまで書いて、常にJWTにsession_idを含めておいて送ることを意図されていた可能性にも気づいたが

それならもっと無駄なため考慮しない

セッションにするメリットとして唯一思いついているのは任意サーバ側でセッションを切れることだが

それを指していたのであろうか

それは最初段落問題と同一と思っている

余談だが、ブコメ雰囲気日和って「ユーザーIDのみ入れ」(そもそもJWTを自然に作れば入るのだが)

というセッションストア的にJWTに他の情報を入れると入れない時に比べて危険性があがることに同意したような記載をしてしまったが

結局JWTが奪えたら中身に関係なくbearerとしてセットして接続するだけなので

正直JWTを使った時点でついでにセッションストアのように使おうが使わまいがセキュリティ的にそこまで変わらないのでは、と思っている

強いて上げるならセッションに保存している内容が分かる可能性があり、サーバー内部の実装が推測できる危険があるくらいだろうか

でも暗号化したらよいのでは、と思った

私的結論

expの期限と任意セッションが切れないデメリットに関して

expを適切に設定しつつ、必要ならアカウントロック機能を入れる

(アカウントロック機能はJWTに関係なく被害の増加を抑えられる可能性がある)

定期的な鍵の交換について

長いkeyを設定すれば不要

「JWTはセッションIDを含めれば安全」について

少なくともapiサーバネイティブアプリに関して、セッションIDを含めても危険性は変わらない

正直webアプリでも大して変わらんのでは、と思っているのは内緒である

と思ったので短慮なところ、見落としている視点があるようなら今後のためにご教示をいただきたく

以上、よろしくお願いいたしま

2018-09-20

anond:20180920185854

計算Unity(のライブラリ)がやってくれるよ

計算意味までは解説してくれないけどな

またブクマカーが知ったかぶってるし

お前らって本当に知ったかぶるんだなぁ

高校行列計算方法を習ってない事が、その後の数学学習デメリットになると思うか?線形独立線形従属概念を学んで行列式が求まること、求まらない事の幾何的な意味を知り、代数法則を知り多次元行列と部分空間価値理解した上でのアフィン変換行列があっての三次元CGでのアフィン変換がある。概念理解しないで単に行列計算が出来る程度の教育なんて無価値なんだからなくなって正解なんだよ。必要人間大学線形代数をやるときに、法則と同時に演算方法原理原則理解すればいいし、逆行列計算方法を覚えればいいんだよ。固有値固有ベクトル意味理解できない半端なプログラマが増えてるのって、高校での機械的教育のせいだろうとすら思ってる。行列使って連立方程式が解けることを知ってる事が、どれだけ意味あるんだろうね?

ブクマカ機械学習がーとかAIがーとか言うけど、必要なのは線形代数II以降の話で、高校でちょろっと計算方法知ったところで無価値なんだよ。逆に線形代数をやるときに変な思い込み負債になるくらいだから無くしていいものとすら教えていて思う。教育としては線形代数統合的にやれば良いというのは間違いじゃないから、削除は改善ですらある。畳み込みのタの字すら知らんアホが機械学習を語るなって。お前らの心配なんか無駄無駄

anond:20180920074911

“単に行列計算が出来る程度の教育なんて無価値AR実装したとき行列計算必要になった。結局ネットで調べながらやったんだけど、過去に触れたことがあるという思いか心理的障壁は少なかった気がする。

結局、このレベルの話になっちゃうよね。こんな程度なら「ゲームプログラミングのための3Dグラフィックス数学」みたいなラノベ入門書)を1日読めば済む話でしかないだろう。AI研究する人たちがどうとか言う話は情報工学科で、将来的に情報幾何必要になった時にキャッチアップできる程度の数学教育をどこまでするのか?って話で、全然次元が違う話。情報工学科を選択する子供を増やすためにプログラミング教育を拡充していく過程で、3DCGの触りをやらせたいとしても、道具として座標変換程度のことをやるのに複雑な知識なんぞは一切要らないからな。だいたいライブラリから関数呼び出すだけで使える。

話は変わるが、数学ラノベなら「ゼロから学ぶ線形代数」がおススメ。あれなら誰でも理解できて、授業でやる計算方法練習より手軽に線形代数面白さを味わえる。

2018-09-17

Windowsのding音は昔はもっと早かったような気がする

Winsows2000とかのころはウィンドウが出るのとだいたい同じような時に鳴っていたが、今はウィンドウが出て1秒くらい経ってからおもむろに1回鳴る

仕事してない感半端ない

ウィンドウ動作にだいたいでいいから合わせろよ

最近常駐するようになってる音質どうこう的なライブラリアプリの出入力と起動のラグだろうか

いやでも昔だってあったぞSoundBlasterのとか

2018-09-13

仕事では完璧にしようとか考えず動く程度に適当に作ればいい

面倒な上司がいろいろ文句をつけてくる

意味不明ものが多いし何かとケチつけないと気がすまない性格から面倒なことを一々と

直接のユーザから意見なら多少は変でもそのユーザ必要としてるなら納得できるし、イライラすることもない

依頼があったわけでもないのに謎の基準文句をつけてくる

社内でそんなことこだわったところで実際には気にされないことが多いのにだ

まだデザイナーデザインについてこうした方がUXいいねみたいなことをいうならわかる

専門の人の意見だし

そうでもないのに何かと文句をつけてくる

増田なのでwebで例をだそう

CSS すらまともに使いこなせずマージンもパディングもないような酷い作りのものしか作らないのにソッチのほうが良いという

色は red, green, yellow と標準のペイントのデフォルトカラーかよというような色を指定してくる

#fcfcfc や #0a0a0a なんて使おうものなら白と黒しろ

max-width を指定せずに画面の端から端まであるようなものがいいという

そのわりにグラデーション無意味につけたがる

一部例じゃなく本音が出たがまぁいいか

今の時代アプリサービスを全く見てないのか?としか言えないようなセンス

自社サービスなんて手を出したらこれは酷いと話題になりそうなもの

見た目にあまりこだわれない社内用サービスしか作ってないからと言って、その他サービスをみてる人からすれば明らかに

残念なしか時代遅れなものが良いと思ってる

しかデザインに限ったことではないがまだ序盤の時点で言っておけばいいものの完成後にいまから変えるなんて難しいのが

わかりきってるようなときになってからああしろこうしろ言い出す

先に書いたようにユーザ要望ならまだ仕方ないと言えるがなぜこんな無意味なことに付き合わなければならないのか


わりと自分完璧主義なところもあるので作るならちゃんと作ろうとしてるんだが

こういうのを相手にしないといけないせいで結局グチャグチャになってくる

色のバランスレイアウトを考えたところで一瞬でそのバランス無意味になるようなことになる

プログラムだって全然関係ないものを無理やり入れ込まないといけないようなことになることも多い

疎結合だとかグローバルをつかわないとかそういう作りやすくするためのことをしていても

それが維持できないような無茶で無意味な指示が出る

根本的に変えたり対処するためのものを作るとかすればなんとかできなくはない

しかしそんな時間はないので結局ひどい作りになるしかない

過去プロジェクトでもそういうのが多いか自分で作るのくらいは扱いやすくしたいと考えていたのだが

過去のもこういう経緯で酷いものになっていったのかなと思う


過去に言われたものだと速度を優先だとか言って自分で作ったものよりは遅くするなと言う

そしてそのコードは本人でしか読めないような酷いものだった

しかしながら関数は使わずコピペだわforeachなどは使わずループ変数を使って地道にやるなどメンテナンス

できる気がしないが速度においては早いと言えるもの

当たり前のようにグローバル変数がいっぱいあるしライブラリ使用箇所はカスタマイズするための仕組みがあるのに

ライブラリ自体をどんどん書き換えていく

便利で読みやすいような書き方だと速度的にはそれに劣る

だがわざわざそんな扱いづらいし見づらいコードは書きたくない

そんなに速度にこだわるなら勝手に一人で機械語でも書いてろよって思う

しかし速度に加えてメンテやすしろという

どちらか取捨選択すべきものなのに両方みたせとか無理なことを言う

ちなみに便利なライブラリは基本無駄が多い遅いものからライブラリ頼みのベンダはクソだとか

能力がないだとか言っていた


そういえば昔先輩社員仕事したときには変に凝ったものとか必要以上に作り込んだりはしないほうがいいとか

言っていてそれなりに手抜きでさらっと一応は動くようなものを作っていた

私はそういうやり方が嫌いだったのだが今ではこういう環境に長くいた結果仕事のものにこだわって作り込んでも無駄

ということがわかってそうなったのかなと感じた

自分でもサビ残休日無償出勤してまでいいものにしようと努力はしていたが謎の指摘に合わせていると

愛着もなくなってきたし後は適当に済ませてしまおうかなという気持ち

ちゃんとした自分なりの完璧ものを作ろうとするなら仕事ではなく趣味で作ってるツールライブラリ

やればいいかと思う


作ったもの次第でユーザが集まる自社のウェブサービスパッケージ商品ゲームなどは作り込む方が

良いと思うが先に値段が決まって受注して作るようなものだと最低限の要望さえ満たしていればあとは

どうでもいい

しろ不便な方が改修依頼が来て稼げる

さらには綺麗で完璧な作りで大抵の想定できる改修は1日とかからないようなものに仕上げるよりも

どこ変えればいいかや影響範囲すらわからいくらいモノのほうが実作業時間が多いのでそれだけ請求できる

先に作り込むメリットがない


ストレスが溜まってきたので発散がてら書いてみたけど疲れてるのかわりと分かりづらい文章になった

けどまぁいいか

そろそろ転職でもしたいなーと考え始めた










2018-09-10

Web系に無駄勉強が多すぎるだけ

https://anond.hatelabo.jp/20180909073549

MSみたいな巨大プラットフォーマーの技術HTMLの規格とかならともかく

JavaScriptライブラリフレームワーク勉強とかマジで無駄

本来経年劣化存在しないソフトウェアを無理矢理劣化させて儲けようとするWeb系の悪質な煽動だと思う。

組み込みこそ本当の質実剛健無駄のない、真のプログラマ仕事だよ。

2018-08-31

anond:20180831144946

わかる

スマホでもいいや(アルテピッツァロマサガ2リメイクよかったし)

そのついでにsteamswitch移植してくれ

いわゆる2番手クラスゲームも当時のCD-ROMゲーム機開発や3D出始めでライブラリがなかったなど

今だと容易に解決される問題が多そうなんだよね

旧スクウェアのゲームとかSSデビルサマナーとかどんどん出して欲しい

グランディアも久々に復活が決まったことだしね

anond:20180830123708

メガベンチャーの連中って

外人が作ったライブラリを使って

vimの設定に勤しむが

サマータイム対応はできず

ディスプレイ複数〜といいつつ人間の目は一箇所しか見れず

キーボードはUS〜といいつつサマータイム対応はできず

なんだが?

2018-08-26

Amazon Musicアプリ」にiTunes楽曲インポートできなくなる件

今朝いつものようにiPhoneAmazon Musicアプリを立ち上げたら、

「×月×日をもってiTunes楽曲インポートできなくなります」といった内容のメッセージが表示された。

え? と思って無意識に画面をタップしたらメッセージが消えてしまったため、日付はきちんと確認できず。

ググってみても、あまり使われていないアプリなのか、twitter上に2件ほどツイートがある程度だ。

それによると、どうやら9月末日をもって、

iTunes楽曲インポートできなくなるらしい。

Amazon公式ヘルプには、インポートできるような記述があり、サービス改変の告知等はない。

そこでAmazonアプリから問い合わせたところ、すぐ返事が来て(←このへんは流石だが)、

仕様変更によりiTunes楽曲Amazon Musicインポートできなくなりました。

この件に関して詳細なアナウンス確認できるページはありません。ご容赦ください。」(原文ママ)とのこと。

どうやらアナウンスせず改変しようとしているらしい。

その程度の些細な改変だとAmazon認識しているのだろう。

が、個人的には一大事

Apple MusicからAmazon MusicMusic Unlimitedに移行したのは、

・iCould Musicライブラリ挙動不安があった

Amazonプライム会員なので少しだけ安い

iTunes楽曲CDから取り込んだり、iTunesで購入した音源)をインポートできる

という理由だった。

iTunes連携できなくなると、

CDから取り込んだ音源CDしか提供されていない)、iTunesで購入した音源などが、

Amazon Musicアプリでは聴けないことになる。

という困った事態・・・

割合でいえば楽曲全体の1割ほどだと思うが、

すげー聴きたいからこそ、わざわざCDで買ったりしているのだ。

またApple Musicに戻る選択肢しかないのか?

なんだか不安定だったiCould Musicライブラリはマトモになったのか?

もう決まってしまたことのようなので、対策を考えないと。。

2018-08-24

ゼロからプロトタイピング的に作る案件が多いせいかバッチ処理とかバックグラウンドタスクのワーカーはマルチスレッドとかマルチプロセスライブラリを使ったりして一つのサーバーの上で全部やってたか

オートスケーリングみたいな複数構成の話を聞くと夢の技術を使ってやってるのかと思ってたけど、大きなアプリとかも最初の頃はそうやっててどこかのタイミングで頑張って一個一個状態を外に出していったりしたんだろうなあ

2018-08-22

何となくスチムーライブラリを見たらゲームが1160本あった

学生時代に集めたゲームのロムと数えたら

16ビット機以前はコンプリート

携帯機もDSまではコンプリート

サターンPSFX64GCWiiまで合わせると2万本くらいあった

残りの人生でもまだまだやりもしないゲームを買っていくんだろうなと諦観する

2018-08-19

作りたいものができた

IT業界SIer下請けで働いている。

土日祝日なしのシフト制だが22時帰宅毎日技術に対する興味が薄れて労働マシーン化していた。



そんな時に Leaflet という面白そうなモノを見つけたWeb地図のためのJavaScriptライブラリらしい。

学生の頃にちょこちょこ記録していた美味しいお店リストや忙しくなる前に遊んでたMMOデータを元にそのライブラリを使ってwebコテンツを作りたくなった。

15年ぶりに「とほほのJavaScriptリファレンス」を見た、今はさっと読んでいる段階だ、IT業界SIer下請け事務処理や保守や問い合わせの対応マシーン化していた

自分にはプログラミング言語を触れたのは15年ぶりだった・・・まったくわからないが読んでいて楽しい

この感覚学生の頃によくあったが社会に出たらいつの間にか忘れて早く帰ることしか頭になかった。

有給休日での代休は取ると元請けからまれ最悪、自分を含めた現場技術者を外すして別の技術者に入れ替えるよう命じられるため休むことができなかったが久しぶりに取った土日の連休

Leaflet と言うものを見てwebコテンツを作りたいなーと思ったときに頭の中で誰かが「もっと休もう、休んで自分のやりたいことを伸ばす時間を作ろう」という言葉自分に掛けた。

休まないのは経営者ぐらいでいい労働者はもっと休むべきだ、今日休日は終わり明日から忙しい日がまた始まる。



でも、これから自分時間重視で働こうと思った。

Leaflet と言うJavaScriptライブラリを使って作りたいものが出来たのだから、きっとこれは何かのチャンスに違いない。

勉強法模索中だができる限り頑張ろうと思う。

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