第3回: ローエンドにもRISC-Vが！ダイソーの完全ワイヤレスイヤホンを分解してみよう：ThousanDIYの「ガジェット分解ライフ」：エンジニアライフ
こんにちは。「100円ショップのガジェット」を中心に電子機器を色々と分解をしているThousanDIYです。 このコラムでは、ガジェットを分解する中での発見や感想をつらつらと書いていきます。 ※タイトルに誤解を生みそうな表現があったので修正しました。(2/2 14:00) Bluetooth接続で左右が独立した「TWS(True Wireless Stereo)イヤホン」、AppleやSonyという大手メーカーから数万円で販売されている高級品というイメージがあったのですが、2021年の春ころから日本国内ではTWSイヤホンの低価格化が一気に進みました。最近ではドラッグストアやコンビニエンスストア、ショッピングセンターにある雑貨店やディスカウントショップでも数千円の製品を普通に見かけるようになりました。 第3回は、そんな「低価格TWSイヤホン」の代表格である、ダイソーの1,100円「完全ワイヤ
引き継ぎされていないからしませんって本気？：Just an ordinary day：エンジニアライフ
みなさま、おはようございます。Kyonです。 前回の"引き継ぎって大事なんやで"コラムを公開する前日に、「引き継ぎされていないからしませんでした」と言われたという話を知人から聞き、「社会人としてどうよ？」とという話になりました。 いろいろ聞いてみると、闇深そうな感じがしたので（？）、めでたくコラムネタ入りと相成りまして候。 お互いの言い分があることはわかる 登場人物を整理しておきます。 知人：私の知人です。 Ａさん：Ｂさんにある仕事を引き継いだ人。知人や周りの人から、対応の良さを評価されている人。 Ａさんグループ：Ａさんを筆頭に、あと他に数名いるグループ。Ａさんの対応方針がよく伝わっていて、他の人に対応してもらっても、Ａさんと同じぐらいの満足度が得られる。 Ｂさん：本コラムで中心となる人。冒頭の「引き継ぎされていないから・・・」と発言した人。 Ｂさんグループ：Ｂさんを筆頭に、あと他に数名い
増14．“テストファースト”と言われて：自転車とプログラミングと：エンジニアライフ
●今回の発端 筆者は直接は言われたことはありませんが、別の所で仕事をしている人などは、「テストファースト」でプログラムを作るのが良いと言われたことがあるそうです（その人は「緑の文字」と言われただけで嫌そうな顔をしていました）。Webの記事などでも見かけます。 もちろん、人間の価値観で軽重の無いプログラムの成果を、人間の価値観に引き込む唯一といっていい方法がテストです。テストは必要です。 しかしながら、“仕事で分担して作業しているプログラマに直接”“「テストファースト」をしろ”と、言われると、まるで「労せず実務上の権限をごっそり奪取しよう」としているように聞こえます。多分、周りの人が手をこまねいていると本当に奪取されるかもしれません。 なぜ、良いことのはずが、こんなにひどいことになるのか？ その辺りを描写したいと思います。 ●背景説明 学生のプロジェクトなどで、 自分一人でやっている デザイ
ついに軽量Rubyの「mruby」のソースコードが公開！：Rails Hub情報局：エンジニアライフ
Rubyの生みの親、まつもとゆきひろさんが、ついに新しいRuby実装である「mruby」のソースコードをGitHub上で公開しました！ 2012年4月20日です。ライセンスは、MITライセンスとなっています。 以下にまつもとさんがmrubyについて語るインタビュー動画を貼り付けます。18分30秒のあたりからどうぞ。インタビューは昨秋の時点でのものです。 公開されたmrubyのレポジトリから、Readmeの一部を引用します。 mrubyはISO規格に準拠したRuby言語を様々な環境で動作可能となるように軽量化したものです。モジュール構成によりインタプリタ実行形式やコンパイル＆VM実行形式でも動作させることができます。 2010年度の経済産業省の地域イノベーション創出事業により開発されました。 MRI(Matz Ruby Implementation)版との互換性 以下要修正 + シンプルな文
IT化とは、単純なことを複雑にすることなのだろうか：Crazy for life（セイカツ イチバン、IT ニバン）：エンジニアライフ
「生活イチバン、ITニバン」という視点で、自分なりのITを追及するフリーエンジニアです。ストレスを減らすIT、心身ともにラクチンにしてくれるITとはどんなものかを考えていきます。 ■それは本当にシンプルか？ むかしはご近所さんが「あそこのお店でセールやってるわよ！」とクチコミすれば誰でもその場に行くだけで、その情報の恩恵にあずかることができた。しかし今は、ちょっとトクをしようと思うと、専用サイトにアクセスしたり専用アプリをダウンロードして、無料会員登録してクーポンをゲットしなければならなかったりする。 クーポンはプリントアウトして持参してくださいね。さもなくば、携帯端末でクーポンページを開いて店員に提示してくださいね。そうすれば割引きいたしましょう。なんですって、ポイントカードをお忘れになった？お客さん、それじゃ今日は割引きは致しかねますねぇ。 これをサービスの向上というのだろうか。 ■恩
ベターJavaScript!? CoffeeScriptが注目されるワケ：Rails Hub情報局：エンジニアライフ
JavaScriptへコンパイルして実行することを前提としたスクリプト言語「CoffeeScript」がちょっとした注目を集めています。CoffeeScript自体は2009年末に登場し、その1年後の2010年12月にバージョン1.0がリリースされていますが、注目を集めたのは、数日前（2011年4月13日）にRuby on Railsの生みの親であるDHHが、次期バージョンのRails3.1でjQueryやSCSSと合わせて、CoffeeScriptをデフォルトとして採用するとTwitter上で発言して議論が巻き起こったからです。 Yes, it's true, Rails 3.1 is going to ship with CoffeeScript and SCSS in the box for use with the new asset pipeline. It's bad ass.
ソースコードの質：気難しいプログラマ：エンジニアライフ
近年、ハードウェアの性能向上などにより、IT業界をめぐるインフラは、ようやく市場の要求に耐えうるようになってきた。以前はプラットフォームの陳腐化によって5年と持たなかったソフトウェアの平均寿命は、ここへきて徐々に延びつつある。 このような状況の中でソフトウェアに求められるものは、繰り返し行われる機能追加に耐えうる「拡張性」と、長期に渡って品質を保てる「保守性」だ。これらの課題については、クラウドのような分散コンピューティング技術や、オブジェクト指向デザインのような設計思想といった大きな枠組みの中で数多く議論され、ソフトウェア技術の進歩を押し上げてきた。「実際の現場においてこれらの課題をインプリメントするのは、システム設計者やSEといった上流工程を任された人間の役目である」と一般に言われている。 彼らのアウトプットは、基本的に文書（Document）だ。文書は日本語や図から構成されており、読
炎上したのでまとめ：ベンチャー社長で技術者で：エンジニアライフ
株式会社ジーワンシステムの代表取締役。 新しいものを生み出して世の中をあっといわせたい。イノベーションってやつ起こせたらいいな。 炎上したので、論点を整理しておく。 1．業務系では効率がトレードオフできない必要条件 業務系の職務では、「効率を求めること」がトレードオフしてはいけない必要条件です（十分条件ではない）。医者でいうならば、「命・健康」と同じ、トレードオフしてはいけない必要条件です。 効率が必要条件にならない職業もあるけれど混同してはいけない。 2．SQLはオブジェクト指向言語の数十倍の効率 オブジェクト指向言語を使い切るのと、全部staticで宣言してしまうような使い方と比べても、効率は数十％も変わらない。 SQLとオブジェクト指向言語を比べたら、数百～数千％の差が付く。 言語や手法を考えるとき、慣れてない人はできないから無限大の工数が掛かる。ですから、できない人を対象に比べても
オブジェクト指向開発を理解した開発者に、設計書は不要：アジアのソフトウェア開発現場にて：エンジニアライフ
シンガポールでアジアのエンジニアと一緒にソフトウエア開発をして日々感じること、アジャイル開発、.NET、SaaS、 Cloud computing について書きます。 わたしのソフトウェア開発者としての経歴は10年程度。10年間、いろいろなものを作ったが、「設計書」と言えるもの、つまり「基本設計書」「詳細設計書」がある形でプログラム開発したことは一度もない。たぶん、これからもないかと思う。 「大したものを作っていないのでは」と、わたしのソフト開発者としての能力を疑う人が出てくるかもしれない。しかし、大企業で大勢の人に使われるようなシステム――規模にして数十年月のしっかりしたシステムを作ってきたことは事実である。ということで今回は、「設計書なしでかなりの規模のシステムを作る」ことに関するわたしなりの方法論を少し書いてみる。 オブジェクト指向は必須である。「設計書なしである程度の大きさのソフト
それは不思議な仕様書なの！？：不思議そうで不思議でないちょっと不思議な現場の話：エンジニアライフ
こんにちは。草食系妙齢プログラマ 野口おおすけです。iPadの予約受け付けが行われましたが、皆さんの購入予定はいかがでしょうか。わたしは、Wi-Fi 32Gモデルを予約してきました。予約番号が後ろの方だったので、当日手に入るか分かりませんがとても楽しみです。 さて、今回と次回は「マジカル仕様書」についてお送りします。マジカル仕様書、つまりは「不思議な仕様書」。実務ではめぐり合いたくありませんが、どうしてもめぐり合ってしまうものです。そんな、憎まれながらも愛すべき存在であるマジカル仕様書についてのお話です。 ■そもそも仕様書って何？ 読者の皆様が、開発業務の中で「仕様書」というものを作成する、あるいは読むことは日常茶飯事だと思います。これらのドキュメントには、開発しているシステムの概要や各モジュールの挙動など、さまざまなことが記述されています。 これらを作成することがゴールではありませんが、
実はオブジェクト指向ってしっくりこないんです！：気分はstatic！：エンジニアライフ
わたしはこれまで、C言語、Visual Basic、SAP ABAP、最近になって ASP.NET C# などの言語を使ってきた。 「自分でクラスを作ってオブジェクト指向っぽいことをしている」なんてことはまったくない。特に「メンバー関数をstatic宣言すればインスタンス宣言をしなくてもいい」ということ知ってからは、メンバー関数を従来のファンクションのように使っている。共有変数も、pubulic static宣言していまう。したがってプロパティなんて作らない。 staticを理解していない人のコードを見ると、いちいちインスタンス宣言しているので笑ってしまう。データベースにアクセスするアプリケーションをC#で書いているのだが、Visual Studioで供給しているSQL関係のクラスを使えばできてしまうのだから。 オブジェクト指向の入門書では、クラスが持つ隠ぺい性が強調されているが、これは他
「ないときは×××とする」と仕様書に書くべからず：ベンチャー社長で技術者で：エンジニアライフ
株式会社ジーワンシステムの代表取締役。 新しいものを生み出して世の中をあっといわせたい。イノベーションってやつ起こせたらいいな。 前回、書いた話ですけれど、気を付けると効果が高いのに、案外とミスる人が多いので、もう一度詳しく。 悲しいことに、わたしがメンテしているシステムで、顧客マスタの請求先、売上トランの請求先に空白があるシステムがあります（まぁ、全部トリガーで埋めるように直したのですが）。 本当にひどい話で、見るたびに血圧が上がります。 これらの設計をしたときに確かにユーザー側は、「空白のときは」とか、「未入力のときは」とかいっています。しかし、ユーザーは空白であって欲しいといったのではなく、「2回入力したくない」ということをユーザーの言葉で説明したに過ぎないのです。 ですから、プロとして普通に言い換えないといけない。 リプレイスがあれば、そのタイミングで直すべきなのですが、プロジェク
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
