by Adam Harvey Linuxを利用していると「シェル」や「grep」「プロセス」といった言葉を目にします。エンジニアのCarl Riis氏はそんなLinuxの基礎用語の意味や仕組みをさまざまなウェブサイトから学習し、「10のミニプロジェクト」を作成することでスキルを向上させたとして、その詳細を公開しています。 Getting better at Linux with 10 mini-projects - carltheperson https://carltheperson.com/posts/10-things-linux GitHub - carltheperson/10-things-linux: Getting better at Linux with 10 mini-projects. https://github.com/carltheperson/10-thing
https://note.mu/kotofurumiya/n/n31d401fce782note.mu 非常によい知見というか、経験談の集まりで、共感するところも多く、興味深く読んだ。大学のプログラミング実習の話のようだけど、企業においても、新卒採用で情報系以外の学科から採用をしている場合、状況はあまり変わらない。 以下、上記記事から面白いと思ったポイントをとりあげて、下記の指標でいったらどのくらいのレベルなのか?を考えていきたい。 satob.hatenablog.com どこまで進んだかな......?えっまだそこ?進んでなくない? ときどき見かける。指標でいうとレベル1~4くらい(スキルミスマッチがかなり大きい状態)と思われる。 ただ「作業が進まない」という事象はプログラミングに限った話ではなく、作業者のレベルによっては一般的な事務作業でも発生する。 たとえば「Excelのこのファイ
この記事は新野淳一氏のブログ「Publickey」に掲載された「AWSをElasticが名指しで非難。ElasticsearchとKibanaのライセンスを、AWSが勝手にマネージドサービスで提供できないように変更へ」(2021年1月21日掲載)を、ITmedia NEWS編集部で一部編集し、転載したものです。 オランダに本社を置くElasticは、オープンソースで開発してきたElasticとKibanaのライセンスをそれまでのApache License 2.0から、商用サービス化を制限する「Server Side Public License」(SSPL)と「Elastic License」のデュアルライセンスへ変更することを発表しました。 その目的は、AWSが勝手にElasticsearchとKibanaをマネージドサービスとして提供できないようにするためであると、同社CEO Sha
具象型ではなく抽象型で扱え、インタフェースを使え、みたいなお話に対して。 前置き Javaの話。他の言語だと話は変わります。 「こうするのが絶対的に正解」と言うものではありません。私の現在の選択の説明です。明日になったら違うこと言ってるかも。 主な登場人物は掲題の java.util.ArrayList および java.util.List、そして java.util.Collection と java.lang.Iterable です。 こんな世界観。他のインタフェースやクラスもたくさんありますが、この話の本筋では無いので触れません。 前提として以下を置いています。 フレームワークやライブラリではなく、一つの業務アプリケーションに閉じた話です。ゆえに不特定多数から使われる型ではなく、影響を与えるコードは全て目が届く範囲にあるものとします。 計算量は別の話です。扱うドメインにもよりますが、
Excel、紙の目標設定・評価シートを豊富なテンプレートでクラウド化。 人事評価システム「カオナビ」で、時間が掛かっていたOKR・MBOの問題を解決! ⇒ 【公式】https://www.kaonavi.jp にアクセスしてPDFを無料ダウンロード GoogleやFacebookをはじめとした、シリコンバレーの大企業が積極的に取り入れていることから注目を集めているOKR。革新的な目標設定・管理ツールとして注目されるOKRとは、一体どのようなメソッドなのでしょうか。 ここでは、その概要や従来の管理ツールとの違い、設定方法について解説します。 OKR・MBOを効率化するなら、目標管理も得意な人事評価システム「カオナビ」です。無料の紹介資料は ⇒ こちらから 1.OKRとは? OKRとは目標の設定・管理方法のひとつで、Objectives and Key Results(目標と主要な結果)の略称
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? はじめに こちらの記事は、技術評論社に寄稿させていただいた「エンジニアリング組織論への招待」をご紹介するための文章です。Qiitaにも再掲しておきます。 アジャイルって何だ? 「ウォーターフォールよりもアジャイルのほうがいいのか?」そんな言葉をIT企業の経営者から聞くことがあります。2000年代の後半くらいから、日本国内においてもアジャイル型の開発プロセスが注目を浴びて、多くの企業が実践するようになりました。 ところが、世界各国に比べて日本のアジャイル型開発の普及率は依然として低く、理解度も進んでいません。流行っているからやってみようと
デザインパターンのよさが分からない人は設計に自信が持てるようになるのか問題自分語りを少々。1 目の前にあった HTML と JavaScript と PHP と SQL が渾然一体となったコードと戦うことから始め、テスタブルなコードを自分が死なないように習得していった自分にとって、鬼門の一つは 再利用のためのデザインパターン だった。 何しろ再利用可能なコードなんてほとんど何もなかったのだ。そんなもの分かるわけがない。 ところが世の中の「ためになる本」はオブジェクト指向やデザインパターンの知識が前提になってしまっているところが結構あって、歯がゆい思いをすることもそれなりに多かった。 そんなところに、少ない設定、少ない知識でもプロダクティブな開発ができる Ruby on Rails というフレームワークが登場したことで、自分にできることが広がった。2 Rails の支援していないもののうち、
最初に周りに結構「今エンジニアやってるけど、将来的にPMになりたい」や、「今学生でエンジニア目指してるけど、いつかPMになる気がする」といった方が多い(自分も昔そうだった)一方、PMをやったことがない人からすると結構どういった仕事をするのかイメージしづらいものかと思います。そういった方向けに、エンジニアとプロダクトマネージャーの役割の違いや、働く上での違いを書いていこうと思います。 補足ですが、ここでいうPMの定義はProject Managerではなく、Product Managerです(PdMと略す方も増えてきています)。この2つは結構混同されがちなのですが(後で触れますが、自分も最初混同していた)、完全に別な役割だと思っています。(これに関しては@kyosu_keさんがこの記事でかなり分かりやすくまとめてらっしゃいます。) エンジニアからPMになるまでの話元々情報科学にあまり興味なか
負債とはなにかについてわたしたちが理解していないという事実そのもの、あるいはこの概念の融通無碍であることそれ自体が、負債の力の基盤である。 デヴィッド・グレーバー 「負債論」 ソフトウェア開発において、欠陥のある未熟な実装によって機能の追加や修正が難しくなることを、借金に喩えて「技術的負債」と呼ぶことがある(Wikipedia)。 現代のソフトウェアはもはや「サービス」に近い製品が多いが、サービスは顧客に受け入れられて初めて収益を生み出すことができる。広く使われているソフトウェアも最初は数少ない機能にたくさんのバグを添えてリリースされ、試行錯誤を経て顧客に受け入れられる。つまり、機能の追加や修正が難しくなることは、それ自体が潜在的な損失と言える。 しかし、私にはこの「技術的負債」という言葉は会計上の「借金」とは随分と異なる意味を持っているようにも思える。というのも極端な話、もし機能の追加や
目的を決めてリファクタリングしよう 「リファクタリングの目的も,その方法もだいたいわかった。でも,いつリファクタリングを行うべきか?」----そうですね。前述のようにリファクタリングはユーザーのためではなく,プログラマのために行うものです。ユーザーから「今からリファクタリングをしてほしい」なんていう要望はけっして出てきません。いつリファクタリングするかの判断は,プログラマ次第というわけです。 ところがデバッグ,機能追加,パフォーマンス改善に比べると,プログラムの構造をきれいにして,拡張性や再利用性を高めることは実際にはかなりアイマイです。「きれいかどうか」という判断には多分に主観が入りますし,拡張性や再利用性も,何をどこまで考慮するかによってずいぶん基準が変わります。こうした作業はある意味キリがありません(注9)。 したがって,リファクタリングをいつ行うか,どこまでするかという判断は案外
この記事には独自研究が含まれているおそれがあります。 問題箇所を検証し出典を追加して、記事の改善にご協力ください。議論はノートを参照してください。(2020年10月) この記事で示されている出典について、該当する記述が具体的にその文献の何ページあるいはどの章節にあるのか、特定が求められています。 ご存知の方は加筆をお願いします。(2014年4月) リファクタリング (refactoring) とは、コンピュータプログラミングにおいて、プログラムの外部から見た動作を変えずにソースコードの内部構造を整理することである。また、いくつかのリファクタリング手法の総称としても使われる。ただし、十分に確立された技術とはいえず、また「リファクタリング」という言葉に厳密な定義があるわけではない。 リファクタリングが登場する以前は、一度正常な動作をしたプログラムは二度と手を触れるべきではないと言われていた。な
Linux Daily Topics 2018年9月19日もう特別扱いはいらない ―Linuxコミュニティに新たな"Code of Conduct"確立へ 現在もLinuxコミュニティを騒然とさせているLinus Torvaldsの謝罪&休養宣言だが、今回の事件をきっかけにLinuxコミュニティ内部から"Code of Conduct" ―コミュニティメンバーの行動規範を新たに定義しようという動きが起こっている。中心人物はGreg Kroah-Hartman(GKH)、現在Linusに代わってカーネル開発を統括する最古参のメンテナーだ。 Code of Conduct: Let's revamp it. - Linux kernel source tree Code of Conductはオープンソースコミュニティでよく使われる言葉で、議論やプレゼンなどの公式の場でどのように振る舞うか
(EAI から転送) 出典: フリー百科事典『ウィキペディア(Wikipedia)』 (2024/02/07 23:28 UTC 版) Enterprise Application Integration(企業アプリケーション統合、以下、EAI)とは、企業内における多種多様なコンピュータシステム群や各種ビジネスパッケージ群を有機的に連携/統合(例えば、営業支援サービスと財務システム、顧客管理システムを連携させ、CRMシステムの機能を拡充させるなど)させ再構築し、より戦略的な機能や情報として提供する機能及びミドルウェア / アプリケーションパッケージや統合技術のこと。 基幹システムと電子商取引システムの接続[1]や、企業間の合併に伴うシステム統合手段としても活用される。
独立行政法人情報処理推進機構(以下、IPA)および一般社団法人JPCERTコーディネーションセンター(以下、JPCERT/CC)は、脆弱性関連情報の適切な流通および対策の促進を図り、一般利用者に対する被害を予防することを目的として、2004 年 7 月 8 日に「情報セキュリティ早期警戒パートナーシップ(以降、本パートナーシップ)」の運用を開始しました。本パートナーシップは、経済産業省の告示に基づき、関係者に推奨する行為を取りまとめた「情報セキュリティ早期警戒パートナーシップガイドライン(以降、本ガイドライン)」に則り運用しています。しかしながら、届出を受けた脆弱性関連情報の中には、本ガイドラインの定義に合致しないことから、取扱いの対象とならず不受理となるものがあります。本ガイドラインの取扱対象を理解することで、本パートナーシップをより効率的に活用できるよう、過去に不受理となった届出のうち
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く