タグ

ソースコードに関するkikuchi1201のブックマーク (5)

  • Panic Blog » ソースコードの盗難について

    先週、動画変換ファイルアプリ HandBrake のMac版によってマルウェアに感染との報道がありました。(日語記事参考: 動画変換ソフト「HandBrake」Mac版にマルウェア感染の危険性 | CNET Japan)2つの配信サーバのうちの片方で、感染したHandBrakeアプリが3日間公開された状態になっており、ダウンロードして起動するとそのコンピュータは攻撃者による遠隔操作が可能な状態になる、というものです。 運が悪く、さらにコンピュータ運にも恵まれず、公開されていた3日の間に感染したHandBrakeをダウンロード、起動したためにプログラマのMacが感染してしまいました。 その結果、どこかの、誰かに、私たちのアプリのソースコードが盗まれました。 続けて、以下の大切な3つについてお知らせします: ・今回の攻撃者がユーザ情報にアクセスした兆候はまったくありませんでした。 ・さらに、

  • フロントエンドが嫌い

    ウェブフロントエンド技術の進歩と興亡の速度には目を見張るものがある。 browserifyが生まれ、Gruntが生まれ、Gulpが生まれた。 そしてその全てが死んだ。 Webpack, Babel, Flow, 今栄えている技術だってそのうちに死ぬだろう。Reactだって例外ではない。 一部はもう死につつあるし、少し前にあれだけ持て囃されたTypeScriptも今や消えつつある。Coffeeは全エンジニアから嫌われた。 そんな万華鏡のように目まぐるしく変わる情勢に追い付かんと研鑽を続ける者等がいる。アーリーアダプターを自称し最新技術のケツを追いかけQiitaにクソを垂れ流す彼らこそ我らがイケイケウェブフロントエンジニアである。 最新技術に目を凝らし、やれ新たなこれイケてるだの古臭いあれはイケてないだのと宣いチュートリアル記事を量産する彼らであるが、彼らの存在は決して無駄ではなく、生まれた

    フロントエンドが嫌い
    kikuchi1201
    kikuchi1201 2017/05/02
    俺はVue.jsとjQueryで心中すると決めた。それ以外はどうなってもいい。そういう気持ちだ。
  • 2016年を振り返って - プログラムモグモグ

    会社は二年目に入り業務にも慣れ、ある程度まとまった仕事を任せられるようになりました。 携わっているサービスのコードに詳しくなり、リファクタリングの方向性を示して改善を進めてきました。 難しい障害も乗り越えながら、引き継いだ手綱を何とか制御できるようになってきたという所感です。 今年は18記事書きました。特に反響の大きかったエントリーは次の3つの記事でした。 内容の方向性もバラバラであまり何したいかよく分からなくなっていますね。どういう技術を学んでいくか悩んでいた一年だったと思います。ブログには書いていませんが、Vimのソースコードをいじったりmrubyのコードを読み込んだりしていた時期もありました。 一年に一つ言語を学べという教えを元に次に学ぶべき言語を模索するために様々な言語を触ってみるというチャレンジに取り組んだのですが、その後とくに新しい言語を触れていないのは反省しています。 少しR

    2016年を振り返って - プログラムモグモグ
  • ひどいコードをメンテしてきたからこそ実感する、良いコードや良い設計の大切さ - give IT a try

    はじめに 先日、社内で「良いコードの書き方やお作法、プログラミングの原則って、どうやったら身に付くんだろうねえ?」という話になりました。 もちろん、「を読んで勉強する」っていのも勉強法のひとつなんですが、そもそも、もっと強烈なモチベーションがないと、必死になって良いコードの書き方やプログラミングの原則って勉強できないのでは?なんて思ったりします。 強烈なモチベーションというのは、たとえば、 いったい何なん!?このスパゲティコードは!!! なんでこんなコードを俺がメンテしなきゃあかんの!!?? あ~、もう最悪や!!俺はこんなコード、絶対に書かへんぞ!!!! っていうぐらいのモチベーションです。 というか、これは単純に僕のケースですね、はい。 幸い、ソニックガーデンに入ってからは、周りのプログラマがみんなちゃんとしているので、そんな思いをすることはほぼなくなりましたが、前職、前々職ではそんな

    ひどいコードをメンテしてきたからこそ実感する、良いコードや良い設計の大切さ - give IT a try
  • 私のソースコードの書き方 - @kyanny's blog

    note.mu なるほど自分も同じような感じでやっているなぁ、と思った。もうちょっと詳しく書くと、 まず変更しようと思っている部分の周辺のコードを読んで、「ここらへんをいじればよさそう」と当たりをつける(当たりのつけかたにもいろいろあるのだが後述) 土地勘を養ったところで具体的な変更の仕方を考える。必要に応じて紙に下手くそな図を書いたり、考えを箇条書きにしたり、実際にコードを試しに変更してみたりする この方針でいけそう、と道筋が見えたらいよいよコードを書き始める。細かい単位でコミットするかどうかは場合によるが、少なくとも git add はこまめに行う(エディタの undo でせっかく書いたコードを失わないため) 道筋が見えなかったり、プロトタイプ的に書いたコードが望み薄そうだったら潔く諦める。煮詰まっていることを自覚して、コーヒーを買いにいったり、オフィスの外を散歩したりして頭をリフレッ

    私のソースコードの書き方 - @kyanny's blog
  • 1