最近、〜歳からプログラマーになってとかキャリア論とかの話を見たりするのですが、 みんなすごい人ばっかりだなぁ思ったので何にもスゴくないド素人がエンジニアになったときに何を考えたのかを書いてみました。 http://koba04.com/slide/become_a_programmer/ 正月でこれまでを少し振り返ってみたのとreveal.jsを試してみたかったのが書いた大きな理由ですが、書いてみるとやっぱりたいしたことしてないのでたいした内容にならないですね。 今年も頑張るぞー
昨日は年始の挨拶ついでに ELPA について脈絡もなく突然書きましたが、引き続き近頃の開発環境についてもだらだらと書いてみよう。 Mosh mosh というと一部の人間はひげなんとかさんが開発しているモナー的なあれを思い浮かべるかもしれないがそうではなく、mobile shell のことである。 思い切り簡略化して言うと「快適なssh」。回線が不安定な所でもエコー遅延など全く気にせず使えるし、Mac をスリープさせて復帰させたときもリモートホストにそのまま繋がりっぱなしのように見せかけてくれたりする。 詳しくはこの辺を。 mosh: MITからモバイル時代のSSH代替品 - karasuyamatenguの日記 インストールはリモートとローカル両方に必要ですが、まあ大概パッケージがあると思います。EC2 の Amazon Linux でも yum レポジトリの EPEL を有効にすれば y
ちょっとした GUI アプリケーションをつくるのに MacRuby はよい選択肢となりうる ちょっとした GUI アプリをつくるのに MacRuby をつかってみた。結論からいうと MacRuby はよくできているなあ、という印象をえた。 昔、RubyCocoa をさわってみたことはあったのだけど RubyCocoa は 「なんか正直 Objective-C の方がむしろ楽な気がする。。」 という感じだった。なにしろめんどくさいという印象しかのこらなかったのである。 一方、 MacRuby はいいな。 Syntax をカスタマイズすることにより無理矢理実現している変態的な感じもよい。実用的。 ちょっとした自分用ツールをかくときに今までは web application としてかいていたのだけど、MacRuby の方が楽だな、そんな気分になったのであった。 (というか、最初 Web Appl
WEB+DB の新しいやつがちょっと前にでてます. コードレビュー特集だそうな. 時が経つのは早い. まだ次の原稿書いてないのに… そういえば前にコードレビューの話を書いた気がして, 見なおしたところ かきかけ だった. せっかくなので続きを書いてみることにします. といっても何書くつもりだったか覚えてないのでだらだらと. WEB+DB PRESS の特集は, 主にこれからコードレビューを導入したい人に向けて書かれている. 幸か不幸か私はコードレビューを義務付けれたプロジェクトで働いているため, 導入には苦労していない. かわりにレビューをちょろまかせない面倒はある. ある意味でコードレビューを <やらされている>. もちろんこの言い分は大げさだ. 必要性に異議を唱える気はない. ただ異議はさておき自分の意向とは無関係にコードレビューに参加している気分を書いた話は あまり目にしないので,
Linux Daily Topics 2012年12月28日Linus怒髪天!─カーネルメンテナーに投げつけた連発F*CK、そのワケは…? SHUT THE FUCK UP! だまりやがれ、この野郎! お前何年カーネルメンテナーやってんだよ!! ──我らがLinus Torvaldsは怒りのボルテージが上がると、相手が誰であろうとF*CKという言葉のつぶてを容赦なく投げつける。だが、今回のLinusの怒りようは尋常ではない。同じF*CKで相手を罵倒するにしても、NVIDIAに中指立てたとき、あるいは米大統領選の最中のロムニー氏を小馬鹿にしたときに比べて、その怒りの度合いははるかに大きい。そしてだからこそ、Linuxユーザは改めて彼を強く尊敬することになる。 まずは英語が得意ではない方でも、以下のリンクを開いてざっと目を通してみてほしい。Linusの怒りのほどがひしひしと伝わってくるはずだ
先日、以下の記事で初めて作ったAndroidアプリを紹介しました。 一週間で初めてのAndroidアプリを作ってみました その後、そのアプリをAndroidマーケットで公開してみました。 はてブ閲覧用Androidアプリ「HTBPocket」を公開しました この一連の作業で参考にした記事やサイトについて、「Androidアプリ開発関連情報まとめ」としてまとめてみました。 開発環境構築まず必要になるのが開発環境です。以下はMacの環境構築です。MacにAndroid SDKをインストール (Update 2010.05.25) そして以下がWindowsでの環境構築です。私はやったことないのでよく分かりませんが(^^;;世界を目指せ!Androidアプリ開発入門:第2回 Androidアプリ開発のための環境構築 公式の開発情報公式の開発者向けサイトです。Android Developers
メリークリスマス! PHP Advent Calendarもいよいよ24日目に突入です。 昨日はxhprofについてでしたね。僕もパフォーマンスチューニングの際に使っています。手軽に利用できるのでお勧めです。 さて、このエントリーでは表題の通りMVCについて書かせていただきます。これは、PHPカンファレンス2012&WordCamp Tokyo2012合同LT大会で発表した「やはりお前らのMVCは間違っている」で煽るだけだったこの問題をきちんと解説するものです。 この発表資料を公開するとPHPの枠を超えて広く閲覧いただき*1、また多くの方から突っ込みを戴きました。「LTだから」と言って逃げていた回答をして、気持ち新たに新年を迎えようと思います。 MVCとはなんなのか 間違いを指摘する前にMVCがそもそもどういうアーキテクチャであるのかを確認しなければいけません。 MVCは1970年代にパロ
ゲームプログラミングにおけるC++の都市伝説 † この記事は、C++ Advent Calendar 2012 22日目の記事です。 Prev 21日目の記事 CEANによる配列操作 Next 23日目の記事 構造化並列プログラミング 時間の関係で3つの都市伝説しかご紹介できませんでしたが、またの機会があれば他の都市伝説についてもお話したいと思います。 2012/12/22 written by h.godai @hgodai 目次 初めに 都市伝説1 C++は遅いのでゲームには向いていない 都市伝説2 boost::poolはゲームには向いていない 都市伝説3 boostライブラリは怪しいライブラリだ。使うと呪われる。 ↑ 初めに † かつて、8bit時代はゲームのプログラムはアセンブラが主流でした。やがて、ゲームのプラットフォームが16bitから32bitになるに従い、C言語でゲームが
このエントリは、 TDD Advent Calendar jp: 2012 の 17 日目の参加エントリです。前日のエントリは [twitter:@shuji_w6e] さんの「軽量なテスト駆動開発を目指して」でした。 久しぶりのエントリです。久しぶりどころか、なんと日記の更新が一年ぶりになってしまいました……(もはや年記ですね)。 昨日、二日間開催された DevLOVE 2012 の二日目最後の(?)講演として、「愛せないコードを書くには人生はあまりにも短い」というタイトルで TDD について講演をさせて頂きました。 DevLOVE では何度か登壇の機会を頂いているのですが、昨日はいつもとは少しだけ違いました。その違いとは「イベントで私以外にも TDD の事を講演する人が複数いる」ということでした。諸橋さん([twitter:@moro])の「テストに開発をもっと駆動させたい」と和智さん
Topcoder is a pioneer in crowdsourcing, with 20+ years of experience, and 325,000+ successful challenges in software development, data science/AI, UX design, and QA. Talk to an expert Topcoder is a pioneer in crowdsourcing, with 20+ years of experience, and 325,000+ successful challenges in software development, data science/AI, UX design, and QA. Talk to an expert Revolutionize How You Get Work D
Facebook のタイムラインに、Wireless Wire News に「海外で食べて行けるエンジニア、食べられないエンジニア」という記事が流れて来た。 簡単に言うと、外でも食べて行ける人は「自分で手を動かして何かできる人」です。 コーディングできる、設計できる、管理の仕組みを考えられる、コストカットした機材の調達の仕組みを考えられる、人員管理がうまい、プロジェクト管理できる、監査の仕組みやドキュメントを作れる、戦略を作って実行できる、という様な「自分で何かができる」人です。 反対に、「これは食べて行けない」という典型例。それは、日本国内の大手ベンダやユーザー企業勤務で、下請けや孫請けへの「丸投げ」しかできない「エンジニアもどき」や「SEというなんだか良くわからない仕事をやっている人」「仕事が部長や課長」という人々です。 基本的には、私が以前、「ソフトウェアの仕様書は料理のレシピに似て
プラットフォームとオペレーティング システム Android → Google AI → Chrome → Google Cloud → Firebase → フレームワーク、IDE、SDK Jetpack Compose → Android Studio → Flutter → Firebase Studio → Google AI Studio → サービスと統合 Gemini API → プライバシー サンドボックス → ID チェック → Google Workspace 成長と収益性の確保 Google Play → Google AdMob Google Ads Chrome 拡張機能 → Google 検索セントラル
2012-11-30 コードの綺麗さの先にあるもの 久々の更新になりますね。せっかくなのではてなブログに移りました。 昨日弊社代表の 「コードが汚くてもいい」っていう社長のインタビュー記事に対して 「コードが汚いのは悪だろ」って脊髄反射してるブクマコメントとかツイートが たくさんあるのでCTOとしての自分なりの意見を書いてみようと思う。 実際の現場 最初に記事を目にしたプログラマー達はまぁ「コードは汚くてもいい」にしか目にいかないだろう。そんな会社で働きたくないって思うかもしれない。この会社には汚いコードが溢れてるんだろうなと。 脊髄反射的にブコメしたり、ツイートされているものは全て拝見させていただいた。 では実際の現場はどうなのか。 盛大に勘違いされてそうだが、そもそもの大前提としてうちのコードは別に汚くない。 綺麗、汚いとかの定義は人それぞれだが、仮にその評価軸をリーダブルコード(可読
あなたにとって重要なトピックや同僚の最新情報を入手しましょう最新の洞察とトレンドに関する最新情報を即座に受け取りましょう。 継続的な学習のために、無料のリソースに手軽にアクセスしましょうミニブック、トランスクリプト付き動画、およびトレーニング教材。 記事を保存して、いつでも読むことができます記事をブックマークして、準備ができたらいつでも読めます。
最近そもそもバッチ処理というものを知らない人達を見ることが多くなりました。某プロジェクトで「いや、ストプロってよくわからないんですよ。最近書いたことないし。」という話をずーっと聞いていたのですが、本人はバッチ処理という意味で話していたことが後から判明した、ということがありました。 ああ、この人はSQLでのバッチ処理しか知らないのですね、とちょっと衝撃ではありました。とうとうそーゆー時代になったかと。 まず、誤解のないようにいうとバッチ処理、という言葉自体はIT固有のものではないです。生産管理や物流や、そういった業務では普通に「バッチ」という言葉をIT以外で使います。ただし意味はある程度同じで、「一定の塊を一度に処理をする」ということです。物流システムの業務要件なんかを詰めているとバッチっていうと、どっちのこと?なんて普通に聞かれたりします。その意味ではバッチの対義語がリアルタイムというのは
EssentialsApplication FrameworksMobile FrameworksMVC FrameworksRealtime FrameworksDesktop GUIServerSide LibrariesTesting FrameworksTemplating EnginesLoadersUIUI FrameworksWindows, Modals, PopupsKeyboard WrappersForm WidgetsUI ComponentsSliders & GalleriesNotificationsWYSIWYG EditorsTouchLayoutTours & GuidesMultimediaGame EnginesPhysics LibrariesAnimation LibrariesAudio LibrariesPresentation Librar
ソフトウェア開発の難しさ ソフトウェアの開発プロジェクトに少しでも関わった人は誰でも知っていると思うが、ソフトウェア作りで最も難しいのは「スケジュール通りにソフトウェアを完成させること」である。 バグがなかなか修正できず泥沼にはまってしまったり、変更され続ける仕様のために当初立てたスケジュール表がまったく役に立たなくなってしまったり、スパゲッティコードに頭を抱えたりということはよくある。出口の見えない状況でソフトウェアエンジニアが過酷な労働を強いられる状況を「デスマーチ」(death march)と呼ぶが、そんな言葉が存在すること自体が、ソフトウェア作りの難しさを表している。 ソフトウェアの開発は「生産活動」ではあるのだが、建物を建てる、料理を作る、野菜を育てる、ハードウェアを組み立てるなどの生産活動とは大きく違うのだ。 建物の場合で言えば、明確に定義された「設計図」がある。そして、その
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く