大学での初心者に対するプログラミング講義ではC言語を使うべきでない - Qiita
今日、大学に入って最初のプログラミングの授業があった。それについて少しばかり思うことがあったのでここに記す。以下の文章は、工学部情報系学科一回生の、最初のプログラミング授業について述べたものである。タイトルにもある通り、この文章は「初心者に対する」講義について言ったものであり、機械制御を専攻する学生に対する講義などを言うわけではない。 最初の言語がC 結論から述べよう。最初のプログラミング言語にC言語は向いていない。できないとは言わないが（私が最初に触れた言語もCだが）、より有力な候補がいくらでもある。私の所属する学科には機械分野に進む人も多いので、それに使われるCを、という思惑もあるのだろう。しかし、初心者が「プログラミングを」学ぶ言語としてはお世辞にも良いとは言えない。私が思うプログラミング初心者に向いた言語とは、次の条件を満たすものである。 現在普及している 環境構築が容易（私の大学
JavaScript初級者のためのコーディングガイド - Qiita
JavaScriptは大変難しい言語です。Rubyの難易度を2、Cの難易度を5、C++の難易度を8にすると、JavaScriptの難易度は12ぐらいあると思います。このコーディングガイドはそんなJavaScriptの深みに嵌まらないようにするためのJavaScriptの書き方を規定したものです。初級者1のための物ですので、わかってやっている人に好きにやってください。 このコーディングガイドは絶対に従わなければならないものではありません。私は一切強制はしませんし、初級者が従わなければならないという義務もありません。採用するしないはみなさんの自由です。 禁止編 JavaScriptには安易に使用してはいけない機能があります。下記の機能は、それぞれの機能を使っても良い、または、使うべきであるという理由を説明できない限り、使用してはいけません。 ==、!= ==と!=を使用してはいけません。代わり
null安全でない言語は、もはやレガシー言語だ - Qiita
これらは、表中の「リプレース対象言語」に挙げたように、多くのメジャー言語に対する代替手段でもあります。 Java の代わりには Kotlin や Ceylon が、 JavaScript には TypeScript や Flow が、 Objective-C には Swift が、そして PHP には Hack があります。 Python は自身に null 安全 を取り込みました。 Crystal は直接 Ruby と連携して使えるわけではありませんが、 Ruby 風の null 安全 な言語です。 Rust は C++ の代替を目指して開発され、 Firefox の一部で C++ のコードを置き換えるのに使われています [^100] 。 null が引き起こしてきた数々の問題を考えると、僕は、 null 安全 は GC （やその他の安全なメモリ管理手法）に匹敵するプログラミング言語の進
技術的負債と戦わずにマネジメントする - Qiita
技術的負債とどうやって戦うか - Qiita こちらを読んで、思ったことを書いてみようと思いました。 記事についての感想 ほとんど同意です！ 凄くまとまっていて読みやすかったです。 ここに書くのは引用記事の別視点での自分の解釈になります。 技術的負債はいつ生まれるか？ 残念ながらアプリケーションのコードを書いた瞬間に技術的負債は生まれます。 どんなに綺麗に書いても、レビューをしても消えることはない闇です。 つまり技術的負債は生み出さないようにするものではなく、コントロールするべきものなのです。 そして、引用元タイトルでは戦う！となっていましたが、 僕は戦い続けて疲れてしまったため、マネジメントすることにしました。 (やることは変わりません) 技術的負債を許容する 技術的負債を細かく返すことは賛成。 ただ、開発者はスケジュールと戦っているため、スケジュール内に必要な機能を提供することが最低限
技術的負債とどうやって戦うか - Qiita
プロジェクトが進行するにつれて増える『負債』 長いプロジェクトに携わっていると、技術的負債をいつ返すのかが課題になってきます。 リファクタリングはいつの時点でやるのか、これは長いプロジェクトを運用していく上で問題になっていきますが、今回は負債の種類を整理し、それぞれどう対応をしていけばよいかを考えていきたいと思います。 私達の開発では常に時間が足りない 最近読んだ、「アジャイルサムライ」という本には下記のようなことが書いてありました。 (開発における)3つの真実 プロジェクト開始時点にすべての要求をあつめることは出来ない 集めたところで要求はどれも必ずと言っていいほど変わる やるべきことはいつだって与えられた時間と資金よりも多い 以上のことからわかるように、私達の開発には時間が無いということが常だということがわかります。実際、技術的負債が多いプロジェクトほどこの傾向が強いのではないでしょう
運用の問い合わせチケットを10分の1に削減した話 - Qiita
Help us understand the problem. What is going on with this article? 会社で働いていると、運用チームからの問い合わせがあると思います。 問い合わせというものは、割り込みに繋がり生産性を下げるのでなるべく減らしていきたいものです。 Redmineで管理されているオープンなチケットを10分の1に削減した話をまとめます。 常時、約50枚ほどオープンなチケットを5枚ほどに減らしました。 問い合わせが多くて辛みを味わっている方の参考になれば。 概要 Web自社サービス タスク管理ツール Redmine 毎日、5枚ほどチケットが増える 運用と開発がそれぞれ20人ほど こんな環境です。 改善のきっかけ うちのチームは、当番制で「問い合わせの窓口」(以下、窓口)となる人を作ります。 窓口の人がチケットを解決したり、有識者にチケットを委譲した
大量メッセージが来ても安心なLINE BOTサーバのアーキテクチャ - Qiita
Help us understand the problem. What is going on with this article? 3月24日に発表になったLINEのBOT API Trial Accountが、いよいよ4月7日から実際に試せるようになりました。既に多くのBOTが開発者の手によって作られ始めたようですね。QiitaにもいくつかBOTの作り方が投稿されていますので、"LINE BOT"というキーワードで探してみてください。 実際の作り方の基本は他の投稿に任せるとして、BOT API自体は非常にシンプルな作りなので、試すこと自体はすぐにできると思います。しかし、シンプルな反面、仮に近い将来「Trial」が取れて、友だち50人制限が撤廃された時、それでも正しく安定的に動作するBOTとするには、アーキテクチャ上の工夫が必要になります。個人的に、既にLINE BusinessCo
関数型プログラミングを業務開発に適用するための架空の社内勉強会資料 - Qiita
関数型プログラミングを業務開発で活用するために HaskellやScala、Erlang/Elixir、Clojureなどの関数型プログラミング言語に興味がある人は多いと思いますが、自分らが日常行なっている業務での開発では到底それらの関数型言語を採用できないのが現実、という場合があるかもしれません。 なので、当面はJavaやGroovy、JS,Ruby,Pythonなどの非関数型プログラミング言語の上で関数型プログラミングスタイルや考え方をなるべく使っていくことでFPの考え方や技法に馴染み広めていき、利点を享受しつつ、将来は大手を振って転職業務開発で本格的な関数型言語を使えるようにしていこうというのが現実的な戦略かもしれません。 以下はそのような目的での洗脳勉強会をやるための架空の資料の目次(案)のようなものです。 「独自研究」の注意 「FPとは何か」の定義について、現時点で一般に合意のあ
引っ越し祝いに大きめのエジプト神像を送りつけられたのでラズパイを仕込んで喋れるようにした - Qiita
プロローグ 恋人と暮らすことにしたので、新しい部屋に引っ越した。 家具やインテリアのテイストも二人で相談して、忙しい日々の中でもくつろげる落ち着いた空間を作ろうとしていた。 そんな幸福な日常が終わりを告げるまで、そう長くはかからなかった。 引っ越しも一段落して、新しい部屋にも慣れ始めたある朝、友人から引っ越し祝いと称して身の丈1mほどの神像が送りつけられた。 古代エジプトで天空神として崇められた、「ホルス神」をしつらえた置き時計だった。 その日からホルス神は、我が家のリビングに鎮座することになった。 準備 というわけで今回は、Raspberry Piを使ってリビングに突如として現れたホルスを喋らせて、さらに目覚まし機能を搭載してみようと思います。 今後エジプト神像を送りつけられた際の参考にしてください。 必要なものはこちら。 Raspberry Pi 2 micro SD スピーカー US
DIS例2 / PHPは配列型と辞書(HaspMap)型が区別不能な言語！ | PHPを使いもせずDISってる君達へ - Qiita
PHPはよくDISられることがあります。しかし、実際にはほとんどPHPを利用していない人が印象だけでDISってることが多いような気がします。 そこで、PHPがよくDISられている点について、実際どうなのかをPHP未体験者向けに解説していきたいと思います。PHPを触ったことない人でもわかりやすいようにシンプル目な仕様のRubyを例に説明していきたいと思います！( Ruby触ったことなくても、その他のOOP言語を触ったことあれば雰囲気は理解できるように書いています ) DIS例1 / PHPは配列操作がしづらい PHPの配列操作は扱いづらい等とDISる人たちがいます。実際のところどうでしょうか。 以下のような処理を配列への中間変数を用いず行うコードを例に考えてみます。 0. [2,4,6,8,10]という配列を用意して 1. ↑の配列から8以下の数だけを選択した配列を作る 2. ↑の配列から各
Scalaにおける最適なDependency Injectionの方法を考察する 〜なぜドワンゴアカウントシステムの生産性は高いのか〜 - Qiita
DIを使わない状態ではUserRepositoryというインターフェースが定義されているのにもかかわらず、UserServiceはUserRepositoryImplの参照も持っていました。 これではせっかくインターフェースを分離した意味がありません。 UserServiceがUserRepositoryインターフェースだけを参照(依存)するようにすれば、具体的な実装であるUserRepositoryImplの変更に影響されることはありません。 この問題を解決するのがDIの目的です。 それではDIのインジェクタを加えて、上記のクラス図を修正しましょう。 謎のインジェクタの登場によりUserServiceからUserRepositoryImplへの参照がなくなりました。 おそらくインジェクタは何らかの手段でサービスであるUserRepositoryImpl(Dependency)をクライアン
さいつよのターミナル環境を構築しよう - Qiita
昔に書いたものなので余り参考になさらずに 僕はターミナルに引きこもっています。たまに外出しても最寄りのブラウザ程度です。そんな僕は Mac を使っています。綺麗な UNIX だからです。ターミナルアプリとしてターミナル.app を使っています。iTerm2 含めいろいろ試しましたがコレがさいつよでした。そして、僕は 2 年半かけてさいつよ環境を築き上げました。 tl;dr 最強のターミナル開発環境の構築する 最強の開発環境を目指して タイトルで豪語しすぎた感はありますが、本気で構築中です。僕がターミナル環境の整備に目覚めたのは学生の時でした。特に何かのプロジェクトに携わるといったこともなく、たまに講義の課題を解いたり趣味のアプリを作成したりといった程度での開発だったので、環境構築や整備に割く時間がありました。 まずは現状 普段のターミナル環境は次のとおりです。 ターミナル.app（全画面）
モダンPHPアンチパターン - Qiita
アンチパターンなので、見出しの内容はすべてバッドノウハウです。 前に書いたやつ PHPのモダンな開発環境を紹介する - Qiita PHP - Functoolsを作った - Qiita PHPのlist()はタプル展開のための機能 - Qiita 関係ないけどこれも: シェル、ターミナル、コンソール、コマンドライン 追記: 本文中でとりあげた「怖い話」について、ちゃんと説明しました PHP - namespaceとBOMに何の関係があるのさ - Qiita ファイルの最後に?>を書く PHPコードは<?phpで始まり?>で締める。それがPHPの常識(ｷﾘｯ ……そんなことはもう綺麗さっぱり忘れよう。PHPはテンプレートエンジンではあるが、Webアプリケーションを書く上では、もはやテンプレートエンジンとしての機能は求められなくなりつつある。 不要な?>を書いてはいけない理由は明確で、<?p
一人React.js Advent Calendar 2014 - Qiita
React.jsについての基本的なところを書いていきます！ 公式読めばわかるようなことが多いですがReact.jsに興味をもつきっかけにでもなれば...。 v0.12.1で確認しています。 こっちは一人で書くように作ったものなので書きたい人はVirtualDOMに書くといいと思います。 (書く人がいなくて1人で書いているわけではない) この記事は古いので下記の更新情報も参考にしてください http://blog.koba04.com/post/2015/03/05/react-js-v013-changes/ http://blog.koba04.com/post/2015/09/22/react-js-v014-changes/ http://blog.koba04.com/post/2016/03/09/react-js-v15-changes/ http://blog.koba04.
GitHub FlowでPull Requestベースな開発フローの進め方 - Qiita
弊社、日本CAWでの開発フローはGitHub Flowをベースにしてpull requestを活用したスタイルを採用しています。 最近、有志のチームでサクっと行きたいラーメン屋さんを見つけることができるアプリ「めんこれ」というのを開発しているのですが、そろそろ開発フローを整備しようという話になったので、今まではクローズドでやってましたが、公開しちゃおうと思ったわけです。 普段はdevelopブランチをメインブランチにしているんですが、スピード感あるデプロイサイクルにするためにmasterブランチをメインにします。 実装者のフロー GitHub Flowについてはこちらの日本語訳を参照のこと。 https://gist.github.com/Gab-km/3705015 GitHubのissueで開発タスクを管理していますので、開発対象のリポジトリで自分にAssignされているタスクを確認し
Ansibleの設定ファイルを使ってServerspecを実行するテンプレート作成用Gem(ansible_spec)を作りました。 - Qiita
Ansibleの設定ファイルを使ってServerspecを実行するテンプレート作成用Gem(ansible_spec)を作りました。Ansible v0.1へアップデートしました。(2015/01/12) 今後はv0.1を使用してくださいm(_ _)m まえがき あけましておめでとうございます。 正月休み中に、タイトルの通り、ansbile_specというGemを作りましたので紹介します。 Gemを覚えたてで何でもGemにしたい症候群に罹っています。 テンプレート作成用Gem(ansible_spec)がすること。 専用のRakefileとspec/spec_helper.rbを生成します。それだけです。 いくつかの決まり事(制限)を守ることで、Ansibleの設定ファイルをもとにSeverspecのテスト先とその内容(ロール)を決め、テストを実行します。 Rakefileとspec/sp
AngularJSモダンプラクティス - Qiita
Help us understand the problem. What is going on with this article? こんにちは、@armorik83です。私のAngularJS歴は2年弱で、これまでAngularJSに関する記事はQiitaにたくさん書いてきました。例えば次のような記事です。 AngularJSアンチパターン集 2014.9 ここらでDirective Scopeの@=&をまとめておきたいと思う 2014.9 TypeScriptで書くAngularJSのMVC 2014.2 AngularJS Directiveの処理順を網羅してみた 2014.12 他にもニッチなものやイマイチだったものも含めてけっこうな数となってきました。また、こういった記事の縁で勉強会でも登壇させて頂きました。 モダンAngularJS 2014.12 GDG中国 TypeScr
破綻しにくいCSS設計の法則 15 - Qiita
ブラウザスタイルは平坦化しておく リセットCSSはオプトアウト可能にしておく 登場頻度の高い組合せはplaceholderとして登録してから利用する 可能な限り画像はスプライト生成してから利用する それ以上分解不可能なコンポーネントは要素のように扱う コンポーネントは自己完結型のものを使う BEMはDRYになるよう粒度を下げる 可能な限り@extendは利用しない レスポンシブでない場所では、Utilitiesクラスを活用する shame.cssはいつも綺麗にしておく 詳細度または特異性の高いものほど後方に記述する 可能な限り!importantしない 可能な限りハックしない 変数をデザインガイドとして活用する CSSファイルを分割するメリットはほとんどないので一つにまとめる 1. ブラウザスタイルは平坦化しておく 例えば、こういうScrap & Buildは単に通信量のムダ。 * { f
開発フロー研修 @ Wantedly - Qiita
Githubでの開発 - Issue, Commit, Pull Request, Mention, Code Reviewに関する基本的なルール ゴール 「 チーム で 長期にわたって 生産性を上げる 」 前提 みんながサービス・プロダクトについて自主的に考える組織 エンジニア全員がそれぞれオーナーシップを持ってよりプロダクトを良くすることを考える いわゆるPM職の不在 = コードは書かずに、マネージだけする人がいない これは組織による。(e.g. 外注やディレクター職の存在) けれど、Wantedlyは、多少変化しつつも、より良いサービスを生み出すために、役割の程度の差はあれ全員がプロダクトについて考え責任を持ったほうが良いと考えている。 理想型 図:「青と黄色」のチーム構成が従来の縦割り+統括チーム、「緑(金)色」のところが目指すべきマイクロサービスチーム マイクロサービスチームは、
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
https://qiita.com/Dronetube/items/ac02a23eafe7d09f3b57