タグ

programmingに関するnyopのブックマーク (436)

  • 新人プログラマーに向けて、技術書の使い方と学ぶ姿勢について【えふしん】 - エンジニアtype | 転職type

    Twitterクライアント『モバツイ』開発者であり、2012年11月に想創社(version2)を設立した有名エンジニア・えふしん氏が、変化の激しいネットベンチャーやWeb業界の中で生き残っていくエンジニアの特徴を独自の視点で分析 藤川真一(えふしん) FA装置メーカー、Web制作のベンチャーを経て、2006年にGMOペパボへ。ショッピングモールサービスにプロデューサーとして携わるかたわら、2007年からモバイル端末向けのTwitterウェブサービス型クライアント『モバツイ』の開発・運営を個人で開始。2010年、想創社を設立し、2012年4月30日まで代表取締役社長を務める。その後、想創社(version2)を設立しiPhoneアプリ『ShopCard.me』を開発。2014年8月1日からBASE(ベイス)株式会社のCTOに就任 みなさん、こんにちは。えふしんです。新入社員として入社されて

    新人プログラマーに向けて、技術書の使い方と学ぶ姿勢について【えふしん】 - エンジニアtype | 転職type
    nyop
    nyop 2015/04/03
    分厚い本で先輩の後頭部を殴打する、疲れた時の肩叩きに、などの正しい使用法が書かれてなくて残念(・д・`)
  • 技術的負債にどのように取り組むか

    みなさんこんにちは。@ryuzeeです。 定期的にSlideshareをウロウロして良い資料がないかを探しているのですが、技術的負債に関する分かりやすい資料があったのでご紹介します。 技術的負債とは、現在の進捗のために、将来のキャパシティ(ソフトウェアの開発能力)を犠牲にすることであるもうちょっと具体的に言えば、技術的負債とは、ソフトウェアの内部的な問題(見つかっているか見つかっていないかは関係はない)、要求の明確化の欠如、ダメな設計、ビジネスの要求に適していない設計、自動化できるはずの箇所の手動処理などを指す**利子の支払いは時間のムダである。**例えば欠陥を直すのに時間を取られる、要求が明確になった後に再度作りなおす、複雑なコードを理解するために余計な時間を取られる、などなど技術的負債の悲惨なサイクルがあるテストを書く時間がない、リファクタリングする時間がない、設計レビューする時間がな

    技術的負債にどのように取り組むか
  • メジャーなプログラミング言語とそれらの役割を、素人でも分かるように教えてください。 - Knoh (ノウ) | The Knowledge Hub

    プログラマーたちは、使用するプログラミング言語と驚くほど密接な関係を持っています。プログラミング言語はあなたをイライラさせ、また教え導いてくれます。あなたはそのうちにプログラミング言語の内部構造や、ちょっとした変な癖を学ぶことになるでしょう。それはあなたの頭のなかにも入り込み、考え方をも変えるでしょう。 正しいプログラミング言語を選べば、新しくて美しい何かを一緒に作り上げることができます。間違った選択をすれば、もちろん面倒なことになります。 言い換えれば、プログラミング言語を選ぶことは、恋人を選ぶことによく似ているのです… (注: 私はストレートの男性です。それ以外の方は、自分の興味に合わせて自由に脳内変換してください) PHP は、あなたが高校時代のある夏、不器用ながらも付き合った初めての彼女です。もっと真剣な関係を築こうとしてはいけません。この子は複雑な問題を抱えています。 Perl

  • 「日本史なんかより、プログラミングを教えるべき」三木谷浩史氏と夏野剛氏が日本の技術者不足を嘆く

    「日史なんかより、プログラミングを教えるべき」三木谷浩史氏と夏野剛氏が日技術者不足を嘆く 三木谷浩史 楽天社長×夏野剛 #3/4 新経済連盟を発足させた楽天・三木谷浩史氏とドワンゴ・夏野剛氏が日の経済や社会問題をテーマに意見が交わしたトークセッション。パートでは、日エンジニアの少なさを問題視する三木谷氏が、「日史より、プログラミングを教えるべき」と持論を展開しました。 規制改革には、コストがかからない 司会:そろそろ、まとめのテーマ。 三木谷浩史氏(以下、三木谷):もうまとめに入っちゃいます? 夏野剛氏(以下、夏野):もうまとめ? 司会:いや、あれですよね。今日一応あれですよね? 夏野:ミッキーが帰るって言うまでやるんだ! 司会:大丈夫ですか? お時間って今日。 三木谷:ちょっとそろそろお腹がすいてきたんですけど。 司会:(笑)。そういう事情ですか。大丈夫ですか。 夏野:ピ

    「日本史なんかより、プログラミングを教えるべき」三木谷浩史氏と夏野剛氏が日本の技術者不足を嘆く
    nyop
    nyop 2015/03/03
    やりたい人がやればいいと思うよ。教えようにもまともに教えれる人いないだろうし。興味を持つ機会なんて昔より格段に増えてるんだから。日本史なんかは逆に学ばせておきたい。漢文はいらん。
  • 弟へ伝える、技術 - ゆーすけべー日記

    Pelletkachels waren ooit eenvoudige apparaten voor verwarming, maar ze hebben een opmerkelijke evolutie doorgemaakt sinds hun bescheiden begin in de jaren ’80 van de vorige eeuw. In dit artikel duiken we diep in de geschiedenis van pelletkachel, bespreken we de belangrijkste mijlpalen en ontwikkelingen op het gebied van subsidiemogelijkheden en werpen we een blik op de transformatie tot moderne en

    弟へ伝える、技術 - ゆーすけべー日記
  • データベース設計についての、僕の知っていることをちょこっと(4) - mike-neckのブログ

    こんにちわ、みけです。 しょぼちむにデータモデル設計について教えてくださいの会 #syoboben - connpass 例によって、適当にテーブル設計について言いたい放題言うシリーズ(?)第四弾です。 今日はヌルになるかもしれない項目について 非ヌル三原則 ヌルになるような項目は「持たず、作らず、持ち込ませず」が原則です。 T字型ER図手法の研修を受けた人からの伝聞では、佐藤正美さんという発案者の方がヌルになる可能性のある項目がテーブル内にあることについて、「出たな妖怪ヌルお化け」とか言ってたとかなんとか… まあ、僕のブログを見るような物好きな人は、null嫌いでOptional<T>を使うのが当たり前の人ばかりですから、テーブルの中にもnullな項目を入れ込んだりしませんよね。 存在しないかも知れない項目 単純です。存在しないかもしれない項目は別のテーブルに分けます。 例えば、次のよう

    データベース設計についての、僕の知っていることをちょこっと(4) - mike-neckのブログ
    nyop
    nyop 2015/02/03
    nullableな項目を外だしにするのは発想としてなかった。いいかも。
  • データベース設計についての、僕の知っていることをちょこっと - mike-neckのブログ

    こんにちわ、みけです。 なんか、こんなイベントが開かれるらしいです。 しょぼちむにデータモデル設計について教えてくださいの会 #syoboben - connpass 僕の方は @mike_neck http://t.co/oZmo4aDp1v こっちとダブルブッキングです!— だいくしー (@daiksy) 2015, 1月 29 ということで、しょぼちむには泣いてもらうことにして(というか、僕が申し込んだ時点で補欠だった)、 参加できないなりにデータベース設計について僕が知っていることと必ずやっていることを少しだけ記述しておこうと思いました。 なお、僕の考えも正解とは言えませんので、マサカリ歓迎です。ただ、このブログコメントが承認制なので、僕が気づかなかったらごめんなさい(m´・ω・`)m ゴメン… なお、しょぼちむがいる会社に川島さんという方がいらして、僕が知っていることを非常に丁

    データベース設計についての、僕の知っていることをちょこっと - mike-neckのブログ
    nyop
    nyop 2015/02/03
    エントリの本文ではないけど、業務アプリの場合、登録日時は証跡として大事なので持たせる派。
  • データベース設計についての、僕の知っていることをちょこっと(3) - mike-neckのブログ

    こんにちわ、みけです。 しょぼちむにデータモデル設計について教えてくださいの会 #syoboben - connpass 上記の勉強会に出られない残念な気分(大してないけど)による憂さ晴らしに適当にデータベース設計について、言いたい放題を書き綴るエントリーの第三弾です。 なお、このエントリーは僕の経験と無知と誤解と独断と偏見によるエントリーであって、正しい(?)とかこうするべきとかみたいなエントリーではないので、読む人は当にここに書かれていることが作成するアプリケーションにとって有用なのかどうか考えてから参考にしてください。 で、今日はそろそろリソースについてって思ってたんだけど、初回、二回目で意識的に無視してきた、ユーザーにとって重要なデータについて書こうと思います。 ユーザーにとって重要な項目たち 前回のアスリートを題材としたテーブルが最終的なリレーションになった時に、元々あった項目

    データベース設計についての、僕の知っていることをちょこっと(3) - mike-neckのブログ
    nyop
    nyop 2015/02/03
    自分も分けちゃう派だなー。
  • レビュアーとレビュイーの関係に関して - 職質アンチパターン

    感じていた違和感の正体がわかった. レビューにおいて,レビュアーとレビュイーの関係には上も下もない. レビューという場では,両者の立場は対等でなければならない.さもなければ,「このレビューおかしい気がするけれど,あの人は立場が上だから指摘しにくい」だとか,「相手は格下だから適当にレビューしても良い」だとか,そういう良くない雰囲気が形成されてしまう. 確かに,レビュアーというポジションはチームの技術力が高い人やそれに伴ってパワーのある人が担うケースが多いと思う.レビュイーはそれに萎縮してしまいがちというか,僕もその1人なんだけれど,そういうのは実際のところ保身でしかなくて,下手に意見言うとレビュアーとの関係悪くなりそう,みたいな卑屈な理屈に基づく駄目な萎縮な感じがする.こういう良くないところはちゃんと直して,健全化していかなければまずい. あとレビューされた内容は素直に受け入れるべきだと思う

    レビュアーとレビュイーの関係に関して - 職質アンチパターン
  • IEEE 754 - Wikipedia

    IEEE 754(アイトリプルイーななごおよん、アイトリプルイーななひゃくごじゅうよん)は、別の表記では「IEEE Standard for Floating-Point Arithmetic」と書かれるものであり、1985年にIEEEによって定められた、浮動小数点算術に関する標準規格である。 GNU coreutilsのマニュアルで「Almost all modern systems use IEEE-754 floating point」と書かれている[1]ように、ほぼ全てのモダンなシステムが使っている浮動小数点方式(の仕様)である。プロセッサ、FPUなどのハードウェア、浮動小数点演算ライブラリなどのソフトウェアで採用されている。 なお、多くのプログラミング言語やその処理系の仕様書では、IEEE 754 に準拠した処理とはわざわざ明記していないことが多い。[注釈 1] つまり実機でIE

    IEEE 754 - Wikipedia
    nyop
    nyop 2015/01/16
    丸めなー。
  • Java SE 再入門

    Apache Kafka Meetup Japan #3 https://kafka-apache-jp.connpass.com/event/58619/ 発表資料

    Java SE 再入門
  • 若手エンジニアが解説するIoT時代の通信プロトコル「MQTT」

    若手エンジニアが解説するIoT時代の通信プロトコル「MQTT」 WRITER : Editorial department IoTが普及するに伴い、大量のデータがネットワーク上を流れるようになる。IoTとはInternet of Thingsの略で、モノのインターネットと訳される。ガートナーの試算では、2020年までに260億個のデバイスがインターネットに接続されるという。IoTが普及していくにあたって、「MQTT」と呼ばれるIoTの世界での利用を想定して作られた、新しい通信形式が注目を集めているのをご存知だろうか?今回は今後利用が拡大していくであろう「MQTT」について紹介する。 ▼関連記事 260億のデバイスがネットに繋がるIoT時代を支える太陽光電池コンポーネント技術 IoT時代の高性能シングルボードコンピュータ「RaspberryPi 2 ModelB」 IoTデバイスに特化したプ

    若手エンジニアが解説するIoT時代の通信プロトコル「MQTT」
  • 金融系メインフレームはなぜCOBOLをつかうのか

    くまぎ @kumagi 「COBOLじゃないとお金の計算は狂うからCOBOLにしか金融系は任せれない」というの、例えばPythonで金融の計算をすると具体的にどういう狂い方するんでしょう? Miura Hideki @miura1729 @kumagi 1円以下を扱うと、普通は浮動小数点数になるからそこで誤差が生じるけど、COBOLは10進演算で行うことと言語仕様で決まっているから大丈夫という話だと思います。固定小数点とかでライブラリ書けばいいんでしょうが、それも手間だし。

    金融系メインフレームはなぜCOBOLをつかうのか
    nyop
    nyop 2014/12/25
    ごめんなさい。ついていけないです。
  • "Microservices"を読んだ

    James Lewis氏とMartin Fowler氏による“Microservices”を読んだ.以前ざっと目を通したが,最近よく耳にするようになったのでちゃんと読んだ.以下はそのメモ. 概要 “Microservices” とはソフトウェアシステムの開発スタイルである 近年このスタイルでの開発を見てきて良い結果が出ている 初出は2012年の3月の“Micro services - Java, the Unix Way” Microserviceは一連の小さなサービスで1つのアプリケーションを開発する手法 それぞれのサービスは自身のプロセスで動いており,軽量な機構(e.g., HTTP API)を通じて情報をやりとりする これらのサービスは独立して自動デプロイされる 一枚岩として構築されるMonolithicスタイルのアプリケーションと比較すると分かりやすい 一般的なエンタープライズのア

    nyop
    nyop 2014/12/21
    ふむー。結果SOAに近くなる気もする。
  • Python入門 : 4日間コース社内トレーニング

    ノンプログラマーエンジニアを対象としたプログラミング言語 Python のトレーニング。演習込みで 4時間 x 4日間 の内容を1スライドにまとめています。 プログラミングとはなんぞや、なぜpythonをやるのかというところから、クラスの継承あたりまでをカバーしています。それにくわえて業務によく利用されると思われる機能を説明しています。Read less

    Python入門 : 4日間コース社内トレーニング
  • IDEA * IDEA

    ドットインストール代表のライフハックブログ

    IDEA * IDEA
  • 【ノンプログラマ向け】プログラマの仕事内容を理解する(1) ~「テスト」という工程が必要な理由 | きのこる庭

    前書き 「一緒に働いている以上、プログラマのことを理解して仕事をしたい」そう考えている企画・ディレクションの方は経験則的に少なくない。 ノンプログラマから見て、プログラマの仕事はイメージが湧きづらく、何故その工程にそこまでのコストをかける必要があるのかわからない事が多い。 プログラマは作業の必要性を説明してくれるかもしれないけれど、専門用語も多いしイマイチピンとこなかったりする。 ここで重要なのはまさに「イメージ」だと思う。すなわちイメージを提供するための良質なメタファーだと思う。メタファーが良質であれば より直感的に理解できる。 実際メタファーの力はバカにならない。「Chef」も「Jenkins」も それぞれ 統一的な世界観が学習者の直感的な理解を後押ししてくれる。 というわけで、今回から数回に分けて なるべく「技術的な話」をせずに イメージを想起しやすいストーリーを導入することで プロ

    【ノンプログラマ向け】プログラマの仕事内容を理解する(1) ~「テスト」という工程が必要な理由 | きのこる庭
  • SQLデータベースに正しインデックスを作るのは 誰の役割?

    SQLのパフォーマンス問題は、SQLそのものと同じぐらいの歴史がある―― ある人は、SQLはそもそも遅いものだとすら言うかもしれません。これは、SQL歴史が始まった頃は正しかったかもしれませんが、今となっては全く 当てはまらないでしょう。にもかかわらず、SQLのパフォーマンス問題は今も一般的でよくあることです。どうしてそうなってしまうのでしょうか? SQL言語は、恐らく最も成功した第4世代言語(4GL)でしょう。その最大の利点は、「何を」と「どのように」 を分離できることです。SQL文は、どのようにそれを実行するかを記述せずに、単純に 何を必要としているかのみの記述になっています。以下のような例を考えてみましょう。 SELECT date_of_birth FROM employees WHERE last_name = 'WINAND'SQLのクエリは、データを要求する英語の文として読

    SQLデータベースに正しインデックスを作るのは 誰の役割?
  • if文の条件式の書き方あれこれ | GuildWorks Blog

    if文の条件式の書き方あれこれ | GuildWorks Blog
  • データとして登録されるビジネスルール - 設計者の発言

    nyop
    nyop 2014/08/27
    ちょっと思ってたのと例が違ったけど概ね同意。スクラッチ系だとビジネスルールをテーブル化するの嫌がる人多いんだよね。