「日記」の記事 - Crieit

初めて学生インターンを受け入れて感じたこと 2019夏

2019-09-17T01:00:01+09:00

はじめに

先月、初めて学生インターンを受け入れた。会社としては随分前から受け入れていたのだけど、うちのチームでは初めてだった。今年は縁に恵まれて受け入れることになったのだけど、自身にとって初めてだったということもあり、気づきや反省をここに残しておこうと思う。

背景

うちのチームの特徴は以下の通り。

会社はいわゆるWeb系の会社
筆者のチームはインフラサービスのためのソフトウェア開発をしている
筆者のチームは福岡が拠点だが、東京のチームと協働してサービス開発をしている
技術スタックはソフトウェアにPythonを、サービスのインフラにはKubernetesを使っている
日本人は筆者だけで他のメンバーは外国籍で、コミュニケーションには英語を使っている

インターン生にしてもらったこと

簡単に言うと、Chaos engineeringをしてもらった。Chaos engineeringについては以下のQiitaの記事がエントリーポイントとして良さそう。

カオスエンジニアリングと聞いてカオスになった人必見

早い話が「システムに対して、有り得そうな障害を意図的に起こして問題をあぶり出し対策を考える」手法と言える。細かいというか、正確に言うと、多少違うのだけど、実際的な視点で言えば、それほど的外れではないだろう。

で、なぜインターン生にChaos engineeringをしてもらったかというと、以下の考えに基づいている。

Chaos engieering（に限った話ではないけど）ではいわゆる"PDCA"サイクルを回しやすく、成果や進捗が把握しやすい
チームとしてChaos engieeringに興味を持っていたが、誰も手を付けることができていなかった
これまでに障害対策のための実装を行ってきたが、それらが本当に機能しているかどうかを確信できていなかった

なお、今回はテスト環境での実施となったので、本格的なChaos engineeringとは違うが、利用したソフトウェアや手法は一般的なChaos engineeringと同じものを採用した。

まず#1 Chaos engieering（に限った話ではないけど）ではいわゆる"PDCA"サイクルを回しやすく、成果や進捗が把握しやすい について。Chaos engieeringを行うにあたって、対象システムをある程度把握してもらってから、どこが問題になりそうかという仮説を立てて、どのように障害を起こすかということまでを最初に考えてもらった。これはChaos engieeringを行うにあたっては非常に重要だ。というのも、Chaos engieeringは意図的にシステムを不調にさせるため、何を行うかをチームでレビューして事前に作業内容を周知する必要がある。その後、作業をしてもらって、またレポートを書いてもらい、結果をチームでレビューした。これにより、自然とPDCAサイクルが出来上がってインターン生の状況が把握しやすくなった。また、副次的な効果として、技術文書の書き方の勉強をしたり、チームメンバーとの関わりを自然に増やすことが出来たと思う。

２つ目 チームとしてChaos engieeringに興味を持っていたが、誰も手を付けることができていなかった は割と重要だと思っていて、チームの誰もChaos engineeringを経験していないのでインターン生がチームでの第一人者となる。よって、周りからマサカリが飛んでくる危険を可能な限り減らして、失敗を恐れずに取り組むための環境を用意できたと思う（希望的な推測）。たとえ失敗したとしても、未経験のチームメンバーにとって全ての結果が貴重な知見となる点も重要だ。

３つ目これまでに障害対策のための実装を行ってきたが、それらが本当に機能しているかどうかを確信できていなかったはインターン生のためというか、プロダクトのためなんだけど、これまでに障害で発生した問題を解決するために色々な修正や機能開発を行ってきた。しかし、同じ問題には対応できているが、同じ"ような"問題に対応できているかどうか、ということまでは確認できていなかった。類似の状況でも、特にエッジケースで、問題なく動作するかという確信が持てるかどうかはインフラレイヤーのアプリケーションでは非常に重要で、Chaos engineeringが良い機会になるだろうと思っていた。

これらの狙いは（筆者の視点では）概ね成功したと思う。結果的に、大きな問題は顕在しなかったが、それはチームメンバーに自信を、プロダクトには信頼をもたらすことになった。

その他に気を使ったこと

週単位で取り組みや成果物を決めて共有した
- 途中で何をして良いのかわからなくのを防ぐため
途中経過や成果を発表する機会を設けた
- 成果物を発表する機会を設けることで、成果物の品質にも気を使ってもらうようにした
チームメンバー以外の社員と交流する機会を設けるようにした
- 会社の雰囲気を知ってもらうために、チームメンバー以外とコミュニケーションをしてもらった

反省点

筆者がメンター役だったが、インターンの後半では放置気味になってしまった。
- 筆者が色々あって多忙になってしまったが、もっと気を使うべきだった。
- 筆者が成果物の完成度を上げるために出来ることは色々あったが、あまり貢献することが出来なかった
もっと早くチームメンバーとのコミュニケーションの機会を持てるようにするべきだった。
- 筆者以外のチームメンバーが英語話者であったため、意図的に筆者とのコミュニケーションを多めにしていたが、いくつかの事柄に対して筆者が上手く回答できず、チームメンバーに頼ることがあった。
- これが結果としてインターン生の進捗を妨げる要因の１つになっていた。
- インターン生のコミュニケーション能力を信じて早くからチームメンバーと直接コミュニケーションできるようにするべきだった。
筆者も含めてChaos engieeringは（知ってはいたが）未経験だったために適切なフォローができなかった
- 今にして思えば、手当り次第にやってみるのではなく、ある程度こちらで想定される問題や事象を整理するなどして、道筋をつけてからやってもらえば良かった

次回に活かせそうなこと

メンター役は業務上のメンター役と業務外のこと（社内の制度や社内でのコミュニケーションなど）を担当するメンター役などを分けたほうが良いかもしれない
- メンターが１人だと業務の遂行に目が行きがちで、慣れない社内での過ごし方や社内手続きなどに関して疎かになりがち
- メンター役の負荷を分散するため
任せる業務はある程度メンター役の社員が精通しているもののほうが良い
- インターン生が詰まったときに的確にアドバイス出来るようにするため。
- とはいえ、Backlogとかをさせてもつまらないので業務の選定は熟慮しなければならない
R&D的な業務にしたのは良かった。もし次回があるなら、お題を与えてProof Of Concept的なものをやってもらっても良いかもしれない。
- インターン生には挑戦的な業務をしてもらうのが良いと思う。インターンが会社のPRの一環だと捉えると、挑戦的な業務を行えるということは会社の良い面をアピールすることにもなるからだ。
- たとえ失敗したとしても、チームはその失敗から得た教訓を活かすことができるし、インターン生は趣味の範囲では経験できないような失敗をするという経験を得ることができる。
- 余談だけど、許容される範囲で失敗をするというのは学習においてとても重要だ。なぜなら、成功した理由というものは説明が難しいことが多く、かならずしもパターン化できない。しかし、失敗した理由を説明することは（簡単ではないが）可能であり、理由がわかればパターン化できるからだ。よって、失敗したほうが成長機会に結びつけやすい。

まとめ

インターンを受け入れたことで、より多くの学びを得ることができた。また、これまで手つかずだったChaos engineeringを導入するきっかけにもなったし、インターン生だけでなくチームにとっても実りのあるものに出来たと思う。とはいえ、まだまだ反省点は多いので、次回はちゃんと態勢を整えて、より良いインターンを提供できるようにしなければならない。

おしまい。

長期化する個人サービス開発でモチベーションを維持する方法〜unityroomができるまで〜

2018-12-18T00:03:29+09:00

こちらはCrieitで開催されている「アドベントカレンダー」18日目の記事です。
何書いてもいいそうなんでちょっとポエミーな記事かきます。

昨日はHataさんの今年スマホアプリを作ってプログラマーになった40代女性の話。でした。
ちょっと感動しました。何を始めるにも遅すぎるなんてことはないですね。

はじめに

まずはこちらの記事をご覧ください。
個人でサービスを作りきるために必要なことが分かりやすくまとめられています。とても有益〜。

個人開発のモチベーションが続かない、作り終わらない。原因と対策を考えてみた。 - フロントエンドの地獄

さて、そこに書かれているような「小さめ」「短期間」「未経験技術は使わない」といったコツを思いっきり無視したらどうなるでしょうか？

今振り返ると笑い話ですが、私の作ったゲーム投稿サイト「unityroom」の開発がまさにそういうアンチパターンの塊でした。

思い立ってから初期リリースまで１年半もかかりました。
なぜそんなにかかったのか、どうやってモチベーションを維持したのか、そのあたりを思い出しながら書いてみたいと思います。

今日の記事は初期リリースまでの思い出話です。初期リリースから２年経過した現在の構成について興味があれば下記記事もどうぞ。
ゲーム投稿サイト「unityroom」に使われている技術 - naichi's lab

実際どれくらいかかったのか

リポジトリや過去ブログを漁ってみました。

2014年
- 12月 Rails Tutorial開始した（Railsの勉強）
2015年
- 4月 ConoHa VPSにChefでRails環境構築を自動化した（サーバー構築自動化の勉強）
- 6月 ConoHa ObjectStorageを使う方法調べる（ファイルアップロード方法の模索）
- 8月テスト認定技術者試験(JTSQB)合格（テスト手法に興味を持ち勉強）
- 10月 SASS(CSS)ちょっと学んだ（Webデザインも覚えたくて勉強）
- 11月 ActionMailerと格闘する(このころがたぶんRailsTutorial3周目)
- 12月 Capistrano3でデプロイを自動化した（デプロイ自動化の練習）
2016年
- 1月本格的にunityroomのプロダクトコードを書き始める（やっと開発）
- 2月 RSpec勉強しながらテストコード書く（開発）
- 4月最低限の機能完成（開発）
- 4月末一般公開！

日付が分かるものだけを書き出してみたらこんな感じでした。

全部で16ヶ月も...かかっている...

前半1年は勉強しかしてないし本腰入れたのはラスト4ヶ月みたいですね。

どうしてこんなことになってしまったのか...

やりたいことが多過ぎた！

こちらの技術説明記事にも書いたんですが、unityroomを作る前に似たようなサイトを運用していました。
（アップロードするファイル形式が違うだけで、どちらも同じゲーム投稿サイトです）

前身となるサイトがあったからこそ、ああしたい・こうしたいという夢が広がっていました。

イケてるデザイン、超使いやすいアップローダ、ユーザー間の交流もしたい。
ランキングもつけたいしスマホでも遊びたい、とか。

運用面でも、FTPで更新するのもう嫌だからデプロイ自動化しよう。
開発者としてテストとか書けるようになりたいなやってみよう。とか出てくる出てくる。

ここまで盛り込むとどう考えてもWeb開発初心者(PHPちょっとやっただけ、Rails未経験、CSSわからん)が1ヶ月で作れるボリュームではありません。

まぁ初心者が作りたいって思ったらボリュームなんて気にしないですよねw

Rails舐めてた！

Rails楽しそう！で勉強を始めましたが正直なめてました。
Railsチュートリアル３周、入門書を２冊、Progateもやって、ブログ記事読み漁って...それぐらいしてやっと馴染んでくるレベル。

Rubyいれるために rbenv ってのが出てきて、Rails入れるために bundler が出てきて、Rails自体にも bundle exec rails xxx とかってコマンドが無数にあります。

さらにPHPと違って共用サーバーじゃ動かないからVPSが必要で、VPSはOSから入れないといけないからLinuxも勉強して、デプロイするために各種ツールが必要で...。（この辺りは後に全部捨ててHerokuに載せ換えることとなります）

下記記事をみてもらうと分かるんですが、Railsにはとてもたくさんの技術・知識が使われています。

あなたがマスターしたのはいくつ？ Railsを習得するために必要な技術要素の一覧 #Rails - Qiita

ほんとRails恐ろしい子！

無計画にRailsをやり始め、「これ何だろう？」って立ち止まるたびにググっては横道にそれ、面白いと感じたら本を読む。
それを繰り返していった結果、非常に多くの時間を費やしてしまいました。

当然ですが、Railsを使う ために全て理解・習得する必要はないです。

行き詰まってもググれば先駆者の記事が見つかりますし、コピペでもどうにかなることがほとんどです。

私の場合は技術習得に比重を置いたため、学ぶ分野が増えてしまいました。

未経験技術に触れ過ぎた！

Railsでアプリをリリースするだけであれば、CI/CD(自動テストや自動デプロイ等)まで手を出す必要はなかったのですが楽しそうなので寄り道してしまいました。

開発中に触れた未経験な技術を並べてみます。（現在使ってないものも含む）

Ruby / rbenv / bundler
Rails / rake / unicorn / puma / gem各種
Sass(CSS)
RSpec
Jenkins / CircleCI
Capistrano3
ConoHa / VPS / ObjectStorage
CentOS / Linuxコマンド各種
Ansible / Chef
Heroku / Heroku Pipeline
Rubymine

書籍が出てるものは買って読んだし、チュートリアルは手を動かしたし、どう使えば開発運用が楽になるか模索していました。

そりゃ時間かかりますよね。

どうして続けられたのか

ふらふらと寄り道しながらもリリースまで続けられた理由を考えてみます。

作りたい具体的なイメージを持ち続けた

前身サイトもゲーム投稿サイトだったので、公開したらどんな感じで使ってもらえるかある程度想像がついていました。

自分もゲームを作っているので、作ったゲームが遊ばれることがどれほど嬉しいか知っています。
気軽にゲームを公開してもらいたい。
可能ならはじめて公開する場として使ってもらいたい。

開発期間が長期化してもそのイメージがずっとあったので、目標を見失わずに続けられました。

普段飽きやすい私が１年半も作り続けられたのは、やはり自分自身が使いたいものを作っていたからかなと思います。

コツコツ続けた

ちょうど作っていた時期、不幸にも往復5時間かかる職場に通勤していました。
（バス＋電車＋地下鉄＋徒歩）まぁ自分で選んだんですけど...

不幸中の幸い（？）、安定して片道1時間電車に座れたのでその時間を開発に当てていました。

1時間っていう時間が「今日はこれをやろう！」と決めてから「ある程度進捗が出はじめる」のにちょうどいいんですよね。

朝進捗があると夜エンジンかかるのも早いです。これが毎日なので少しずつですが着実に進みます。

こんな生活を1年続けたので勤務日だけでも2h*220日=440時間...元気があれば帰宅後や休日もやってたので結構な時間やってますね。

フルタイムの業務に加えて残業60時間＋通勤100時間かかってました。なのに電車で寝ないで開発するとか今考えると頭おかしいですね

GitHubに草生やすのも楽しい

naichilab | GitHub （これは2018年のグラフ）

GitHubにはコミットをグラフ化する機能があります。

よーし１コミットだけやるぞ！って机に向かったらめっちゃ捗ったりとかありません？？

小さな達成感のコントロール

多くの未経験技術に触れたと書きましたが、どれも楽しみながら学びました。

わかりやすく書かれた入門書を読むことは、比較的安価に達成感を味わえるのでオススメです。

達成感①：スラスラ読めるので数日で１冊読み終わる
達成感②：知らない技術を分かった気になれる
達成感③：上記①②から、着実に進んだと思いこめる

まぁ本読んだだけでは使いこなせないです。それは問題ではなくて、少なからず知識が増えたことを喜ぶことが重要。

メインの開発が行き詰まったとき、しんどい思いしながら続けると病んでしまいます。
そういう時はストレス解消だと思って気軽に別の技術に触れています。

ストレス解消できて成長も感じられていい感じ。

焦らない

誰でも無料でサービス開発ができる時代になりました。日々数多くのサービスがリリースされています。

素晴らしい品質のサービスもたくさんあり、自分のサービスと比較すると着眼点・技術力の差に目眩がします。

それでも今の自分に出来ないことは出来ないので焦っても仕方がないです。

１つ１つの開発を急ぐより、多少時間がかかっても着実にリリースすることを重視したいです。出し続けられることの方が大事。

千里の道も一歩から。

楽しく開発して長く続けましょう！！！

まとめ

unityroomの開発が長期化した理由と、モチベーションを保ってリリースできた理由を思い出しながら書いてみました。

人によってモチベーションのコントロール方法は違うと思います。
どのような方法が合うのかもやってみないと分からないことが多いです。

今日書いた内容が、1000人に1人でいいのでモチベーションが尽きかけてる人の一助になれば幸いです。

一緒に開発を楽しみましょう〜！！

明日はPorinさんです！お楽しみに！

vimとかtmuxとかを使いこなそうとしない

2018-11-15T10:25:03+09:00

Google Cloud Shellの中でやれることをやる。高価なPCやサーバーを用意しなくてもブラウザだけで従来の「プログラミング」をすることができる。評価の定まった本に書かれたコードを書いて実行できる。いま始める人のためにピッタリ。

Google Cloud ShellにはWebエディターも用意されているけど複雑だから使わない。
vimがインストール済みだからvimを使う。

$ vim index.html

ややこしいことは考えずに、
ESCとiと:q!と:qwだけで十分使える。
ESCキーの代わりに使えるctrl + [ が便利。

設定しなくても色が付いてるし、自動で閉じタグ書いてくれる。
ただ、タブ幅が大きすぎるからvimrcファイルで設定する。

~/.vim/vimrcファイルを置く、中身は3行。

source $VIMRUNTIME/defaults.vim

まずこれを書くこと。これがないとすっぴんで起動して、htmlのハイライトもされない。

set tabstop=4
set shiftwidth=0

これでタブ1文字の表示がスペース4つ分になる。

index.htmlを書いたら、プレビューする。

Google Cloud Shellの「ウェブでプレビュー」は、インターネットからアクセスできるURLを用意してくれる。googleアカウントでログイン済みのアクセスだけをcloud shellの8080ポートへ通してくれる。
ということで、8080ポートで待ち受けするWebサーバーを起動する。何を使ってもいいんだけど、インストールされててすぐ使えるからpython3。

$ python3 -m http.server 8080

実行すると、画面から入力待ちのプロンプトが消えてWebサーバーのログが表示されるようになる。こうなるとvimが使えない。Webサーバーを起動したままで他のこともしたい。cloud shellの別のタブを使ってもいいけど、Google Cloud Shellはtmuxが導入済みで、こういう場面で役に立つ。

ctrl + b, cを押すと、「Wellcome to Cloud Shell」が表示される。さっきまでの画面はctrl + b, nで戻れる。迷子になったときはctrl + b, wで画面の一覧が出せる。

これで、Webサーバーを起動させたままvimでhtmlファイルを編集できる。

vimを終了させずにファイルを保存するには、:w

Brackets VS Atom

2015-11-26T16:11:10+09:00

BracketsとAtomの比較だが、Atomの方が優勢だと思う。

・Bracketsはホイールのスクロール量がおかしく、
上下分割をしている時にスクロールしすぎて使いものにならない。

・Bracketsで1000行以上のファイルを編集しているとカクカクになる。
Atomで同じファイルを編集してもかなり軽かった。

・Atomは行番号クリックで行選択ができる。
これができないBracketsは正直かなり使いづらい。

・Gitがきちんと使えそう。
Bracketsも拡張機能はあるがかなりしょぼい。

・ファイルツリーの行間が広く扱いづらい。

とりあえずBracketsはもっさりしすぎている。
小さいファイルばかり扱うのであれば全然困らないし快適だが。

メーラーを卒業

2015-01-21T16:01:26+09:00

PCの調子が悪くなってきたので以前に元々ゲームで使用していたスペックの高いPCに乗り換えた。
それに伴いthunderbirdを卒業した。

元々、その前にPCを乗り換えた際に、thunderbirdの設定をimapのみにしていた
（以前使っていたプロバイダのメールなどは全部gmailに傳送している）
のでいつでもgmail通知に切り替えられる状態ではあった。

ただ、切り替えられなかった理由としては、
一つのこだわりとして仕事の時間外に仕事のメールを通知されたくない、
というところがあったため。

今回色々調べてみると、checker plus for gmailというchromeの拡張機能は
複数のgmailアカウントの通知をできるのだが、
オプションで各アカウントを無視することもできる、という機能があった。
試しに使ってみると、それほど面倒ではなく使えるように思った。

１日と仕事はじめと終わりにこのオン・オフをしなければならないのだが、
まあどうせメーラーでも起動、終了をしなければならないのだから
それほど大きな違いはないかな、というような気がしている。
それよりもPCを汚さないのとブラウザさえあればどこでも全く同じ操作ができてしまう
メリットのほうがだいぶ大きいと感じた。
gmailの操作性は現状だと全然悪くないし。

PHPExcelで画像貼り付け時にsetOffsetYが効かない

2014-12-26T16:12:11+09:00

PHPExcelでシート上に画像を貼り付けるサンプルがネット上で見つかる。
そこではまず貼り付ける位置をD20等で指定し、
その後setOffsetXを使ってX座標の微調整をするのをいくつか見つけたのだが、
setOffsetYを使ってY座標の微調整ができない。

setOffsetYというメソッド自体はあるのだが、位置が変わらない。
動作していないか、別の用途で使われるものだと思う。

ではどうしたかというと、
例えばD20のちょっと下に貼り付けたい場合、
D20の縦幅を狭くし、D21の幅をその分広げて、
D21に画像を貼り付ければいいだけだった。
ページ上を左右の段組とかのように作っていると難しいかもしれないが。

昨日のラジコンの配線図

2014-05-14T11:05:15+09:00

昨日のラジコンの配線図。

まあ見にくいしぐちゃぐちゃにして書きなおしたりしてるので
何の参考にもなりません。

この紙はサンハヤトの基板をネットで調べたら
印刷用のがあったのでそれ。
ユニバーサル基板でぱぱっとちっちゃいもの作りたい場合は
便利かなと思う。
かなり見にくいので蛍光ペンや複数色ボールペンがあると楽そう。

Eagleはとても時間がかかって挫折中なので…。
みんなはやっぱちゃんとそういうのでやってるんだろうか…。

秋葉原の電子部品関連店舗に行ってみた

2014-05-10T19:05:59+09:00

秋葉原に行く機会ができたので色々行ってみた。

・秋月

店舗は狭く、しかし人が多いのですごいことになってた。
とりあえずICソケットやモータードライバ等を頑張って探して、
必要な物だけ急いで探して買う、みたいな雰囲気でのんびりできなかった。
休日だからっていうのもあっただろうが…。
のんびり色々見たい場合は平日か、埼玉の店舗に行ったほうがよさそうだ。

・千石

こっちはネットで見ると秋月ほど安くないんだけど、
店舗がいくつかに分かれていて（どれもそばに並んでいる）
かなり商品数もおおくゆったりしていてだらだら見るのにも楽しそうだった。
ここでは小型モーターがあったので４つくらい買った。
タミヤのパーツがたくさんあったので
モーターを使って色々やりたい人とかは楽しそうだ。

・aitendo

なんかへんてこりんなところにあり、
何故かネットやGPSもうまく機能しなかったので見つけるのに苦労した。
かなりこじんまりとしている。
ていうかこれ

なんかちょっと店舗のブログかなんかに掲載されていた、
なんかのイベントの時に作られていた基板が２枚までFREEだったので笑ってもらってきた。
他にも、基板 in MINTIAとか、面白いちっちゃい基板がたくさんあったので
見るだけでも楽しめた。
ここではその場で見た基板を適当にいくつか買った。
オンラインショップのカテゴリだと
商品カテゴリ一覧: ★色々な電子部品 > PCB
とかみたい。

・ダイソー

これは秋葉原ですらなくうちから数駅離れたところにある
超でかいダイソーなんだけど、
ネットではんだ吸い取りポンプがあるという噂を聞いていて、
電話して聞いてみたら売られていたので行ってみた。
秋月では800円くらいなのにダイソーは200円。

商品を見つけたのだが、なんとはんだごてまで500円とか売られていた。
日中に急にはんだごてが壊れた、なんてときに役立ちそうだ。
ほかにも逆ピンセットや熱収縮チューブとかがあったので
適当に買った。
すごいなダイソー…。

ただ、はんだを溶かしてすぐに基板を振って叩くと
半田がするっと取れる、という情報も得たので
そっちも試してみたい。職人技だな…。

Dealextremeで買ったICソケットが…

2014-04-30T18:04:26+09:00

曲がってる…。
Dealextremeで購入したゼロプレッシャーICソケット。

海外に品質なんて言葉は存在しなかった…。
まあ8サイズセットで1000円の激安だからお得なんだけど。
壊れてないだけまだいいか。
壊れない物、壊れても良さそうなものを買おう…。

ちなみに到着は2週間くらい。
tracking numberは表示されていなかった。

電子部品の通販サイト感想

2014-04-15T13:04:01+09:00

今までに使った電子部品関連の通販サイトをまとめてみる。
（使ってないのも混じっているが）

・秋月電子通商

言うまでもないが安くて品揃えの良いメインでつかえるお店。
送料無料とかはないので計画をたてて必要な物は一気に買いたい。

・千石電商

店舗は一番品揃えが良いのでは、ということらしい。
凄く安い、ということはないので必要な物がある時に利用したい。

・イトウ電子部品・通販

意外と安いが、個人でほそぼそとやっている？　ようでクレジット決済も無い。
(いつのまにかクレジット使えるようになったみたい)
ただ、１個だけ買っても送料が200円固定とものすごく安いので
ちょっと何か買い忘れた物があるときとかに利用できそう。
振込手数料がかかると意味ないので楽天銀行とか持ってるとよい。

・aitendo

ここはなんか品揃えが面白く他にないものとかがあったりする。
USB-シリアル変換モジュールが500円で売ってたりしてすごい。

・スイッチサイエンス

とりあえずarduino関連はここで買いたい感じ。
3000円以上で送料も無料だから欲しいものが気軽に買える。

・DealeXtreme

海外のサイトだがまさかの送料無料。
しかも異常なまでに商品が安い。
送られてくるまでにかなり時間がかかるみたいなので
急ぎでないものはここで買っちゃってみてもいいかも。

以下はお店ではないが…

・ちっちゃいものくらぶ

arduino関連等のオリジナルキットが売られている。
組み立てなどは必要な物が多いが、全てかなり安い。
完全個人なので届くまではのんびりで時間が掛かるが
計画的に注文していけばかなり費用を抑えて遊べる。

・ヤフオク

掘り出し物多数。

firefoxがずっと応答なし

2014-04-07T13:04:11+09:00

今日突然、
firefox起動
→しーん…
→だいぶ経ってから真っ白なウィンドウ表示
→そのままずっと応答なし
という現象が起きた。

なんかタブの復元ページが表示されたと思っても
tabbrowser.xmlのスクリプトが動かないから
待機するか終了するか選べとか言われるし。
応答なしだからたまーにしかボタンをクリックできない。
クリックしてもまた同じ確認ウィンドウが出てくる。

プロファイル変更してもダメ
セーフモードでも同じ
firefoxふざけんなまじで仕事が出来ない

結局プロファイルをバックアップして再インストールしたら
起動できるようになった。
かんべんして欲しい。

モータードライバでモーター制御

2014-04-05T09:00:00+09:00

100円ショップのモーターで動く電車を
リモコン操作出来ないかと思い回路を作っていたのだがようやく完成した。
モーターはモータードライバをかませてある。

とりあえず単三電池４本でやってみると想定通りに動いた。

次にＨＴ７７５０Ａというステップアップコンバータの回路を作って
単三電池１個で試してみたのだが動かない。
テスターで測ってみてもなぜか３Vちょいしか出てない…。

その後試行錯誤してボタン電池に変えてみたり
モータードライバへの電源入力を分けてみたり
ボタン電池3V2個を重ねてみたりしたのだがそれもダメ。

同じ６Vでも足りないのは電流不足だろうか…。
ともかくちゃんと電力がないとだめっぽい。
もともと電池１個で動いてたおもちゃなのに…。まいった。

追記…
http://www.geocities.jp/plarailn700/page88.htm
はプラレールの改造を行っているサイト。
回路を見るとリレーというものを使っていた。
これで電池１本でいけるじゃないか！！

swfmillのインストール(追記)

2010-11-04T09:00:00+09:00

さくらサーバー以外の専用サーバーなどにインストールする際のまとめ。
前回は
http://program.alphabrend.com/?p=45

yum install gcc-g++
yum install libxslt-devel
yum install freetype-devel
yum install libpng-devel

pkgconfigが必要な場合もある。