Python vs Ruby vs PHP vs Haskell プログラミング言語バトル part1
42 : デフォルトの名無しさん : 2011/11/12(土) 23:53:51.20Pythonの方が弄れる対象が多いのに、なんでウェブ系だとPHPの方が流行ってんだろ 端末からのテキスト処理も楽だし、数値計算周りのライブラリも充実しているのに PHPが優遇されているのって歴史的な経緯以外に何か他の理由でもあるのか？ けどまぁ、情弱な文系SEが大半を占めているバカだらけの日本じゃ別にPHPで困ることもないか 45 : デフォルトの名無しさん : 2011/11/13(日) 01:41:24.25数値計算や端末からのテキスト処理なんてWeb系じゃ大して使わないからなあ… 43 : デフォルトの名無しさん : 2011/11/13(日) 00:04:23.30PHPが未だに現役なのは、単に歴史的な経緯でしかないだろ Pythonに関しては、ZopeさえコケていなければWebサーバ用LLとし
糞コードは直すな。 - Qiita
とりあえず落ち着け。 みなさん、毎日なにかしらのコードを読み、開発する日々を送っていると思います。そんな中で、 糞コードは死ぬべきである！！絶対に直すべき！！ という感情に取りつかれてしまうことがあると思います。自分の技術力に自信のある人ほど、無理やりにでも直そうと試みると思います。それがどんな修羅の道か。そして、糞コード修正がどんな道を歩むのか。この記事では糞コード修正の罠とありがちなストーリーについて書きたいと思います。 ビジネスとしてのプログラムは本質的に糞である 例えば、「携帯電話の利用料金」のプログラムがあります。 「携帯電話 透明性高め料金値下げを」という記事もあるように世の中の携帯電話の料金プランはかなり複雑です。例えば、auだと「auでんき」といった電気料金とパックされた電話料金プランがあります。また、「auスマートバリュー」といったプランもあり、家のインターネット回線をa
Javaで書いた4行のコード、依存関係をたどると51万行に――超複雑化するソフトウェア構成、SBOMで探るには
＠IT編集部は2022年8月22日、デジタルイベント「＠IT ソフトウェア品質向上セミナー」を開催した。基調講演では、「SBOMによるサプライチェーン攻撃対策～自社ソフトウェアのリスク、把握していますか？～」と題して、JFrog Japanの横田紋奈氏（デベロッパーアドボケイト兼Java女子部・JJUG運営）が、企業におけるオープンソースソフトウェア（OSS）の使用に潜むリスクにはどのようなものがあり、それにどう対処していけばよいかについて解説した。 ソフトウェアのセキュリティで注目されるソフトウェアサプライチェーン攻撃 SBOMとソフトウェアサプライチェーンの話題の前に、横田氏はDevSecOpsとは何かから話を始めた。DevOpsは、開発者と運用者が協力してサービスを改善していくもの。ユーザーからのフィードバックなどを受けて取り組みを繰り返し、改善を継続する。そのための考え方であり、組
ソースコードを公開したソフトウェアで収益を得ている会社
ソースコードを公開したソフトウェアで収益を得ている会社をまとめる。いわゆる「オープンソースソフトウェア（OSS）」という有名な言葉を使わなかったのは、OSS の定義に当てはまらない、またはその可能性があるものが含まれているため。 この記事では "OSS" の定義に当てはまらないものも含め、主要な事業を構成するソフトウェアを一定のライセンスの下で公開している会社をまとめていく。このようにソースコードを公開して利用者やフィードバックを集めるビジネスモデルは open core とか COSS: Commercial Open Source Software と呼ばれているようだ。 企業が「ソースコードが公開されているソフトウェア」を利用するメリットとしては、主に以下の2つがあると考えられる。 コア機能の開発に集中できる 自社のビジネスの核となるソフトウェアの開発に集中し、それ以外の機能的・非機
作業量を稼ぐために、日々気をつけていること | pyama.fun
僕はよく手が早いと言われるのだけど、そんな中で気をつけてることを整理してみた。大きくは下記の３点につきる。 複数タスクは抱えるが、並列で進めないイベント駆動で動くことを原則として、探索行動をしない暫定対応ではなく、最初から必殺する複数タスクは抱えるが並列で進めない僕はだいたい平時2〜4くらいのタスクを抱えている。しかし、だいたい1個〜2個に集中して片付けて、次に手を付けるっていう感じで進めている。 この2つをさばくときは、例えば1つ目のタスクのコードを書ききってしまって、レビュー待ちとかの問に、2つ目のタスクの設計を考えたり、あれこれ進めて、レビューコメントが付いたらまた1つ目に戻ってぐわーってやる感じ。もう少し小さいスキマ時間、例えばchefのapplyとかコンパイルだとSlackで適当に人に絡んでわけのわからないことを言って去るという感じのことをしている。 ともあれ、これの利点は基本的
ドキュメントはなぜ書くべきなのか - inductor's blog
はじめに 最近、仕事・プライベート問わず技術的な内容に関して人に教える機会をいただくようになりました。 僕は前のチームの影響で文章を書くことの重要性を意識するようになりましたが、最近はどうしても面倒で後回しにしがちなドキュメントをどうやったら書けるようになるかということについても考えています。 なぜドキュメントは大切なのか ドキュメントの重要性は、個人的な感覚ではテストコードに近いと思っています。 特にプロジェクト初期や設計の段階では、「なぜその技術を選んだのか」や、「なぜこの方針にしたのか」といったことを議論したり、複数の選択肢から技術を選定するためにさまざまな比較検討を行います。 このとき、決めたことはコードとして残りますが、「検討したが採用しなかったアイデア」についてはコード内ではなかったものにされ、見えなくなってしまいます。正確に言うと、コードとしては不要なものはいらないのでそれは
［速報］「Amazon CodeGuru」発表。機械学習したコンピュータが自動でコードレビュー、問題あるコードや実行の遅い部分などを指摘。AWS re:Invent 2019
Amazon Web Services（AWS）は、米ラスベガスで開催中の年次イベント「AWS re:Invent 2019」の基調講演で、機械学習を用いて自動的にコンピュータがコードレビューをしてくれる「Amazon CodeGuru」を発表しました。 Amazon CodeGuruのコードレビュー機能は、Amazon自身のこれまでの大量のコードと、GitHubで公開されているポピュラーな1万のオープンソースソフトウェアのコードを基に機械学習のトレーニングを行ったモデルを用いて、対象となるコードを解析。 GitHubやCodeCommitのプルリクエストと連係し、問題があるとされた個所には人間に読める形式でコメントをしてくれるというもの。 並列処理や脆弱性の問題あるコードを指摘 例えばAWSにおけるベストプラクティスのコードから外れているものや、並列処理における問題などの指摘。
システムの寿命はコードで決まる！（1/3） ― ＠IT
コードはシステムの寿命に大きな影響を与えます。今回は、コードとデータベースエンジニアの関係を通してこのことを解説します。ここでいうコードとは、顧客ID、受注伝票番号など、業務上利用されるデータを識別・分類するため、各データの本来の名前とは別に割り当てられる記号のことです。 データベースエンジニアにはデータ設計とデータベース設計の2つの役割があります。そして、データベースエンジニアにはデータ設計の一環として安定したコード体系を設計し、データベースをコード体系に依存しないように設計することが求められます。 システムを長く使い続けるためには、 コード体系を長期にわたり変更せず利用できるようにすること コード体系とデータベース設計との結合度を小さくすること が重要です。なぜなら、コードのけたが足りなくなったり、コードの分類が業務にそぐわなくなったりして、コード体系の見直しを行うことになると、業務・
教えて、ござ先輩！ なぜプログラミングに「表現力」が必須？ わずか3つの表現文法でイメージをコード化する方法 - エンジニアHub｜Webエンジニアのキャリアを考える！
教えて、ござ先輩！ なぜプログラミングに「表現力」が必須？ わずか3つの表現文法でイメージをコード化する方法 自分のイメージを、ちゃんとコードとして表現することができていますか？そのために必要なのは、イメージを論理へと変換する、「表現力」です。エンジニアが身につけるべき表現力を、ござ先輩がばっちり解説します！ 株式会社クオリティスタートの代表を務めている、湯本（@gothedistance）と申します。インターネットでは、「ござ先輩」という愛称でブログを書いたり、雑誌やWebメディアに記事を書かせていただいています。本業ではITコンサルタントという立ち位置で、主に業務アプリケーションの業務分析/要件定義や、エンジニア向けの新人研修の講師などの仕事をしています。 プログラミングは非常に自由なもので、同じ処理や条件を記述しているにもかかわらず、エンジニアによって書かれたコードがかなり違うことが
設計の原則：モジュール化 | システム設計日記
ソフトウェア設計には、パターン理解が大切。 でも、その前に、設計の基本原則（設計の基本テクニック）を、押さえておきたい。 いろいろな設計パターンに共通する、その根っこにある設計原則を会得すれば、パターンの理解や実践が、もっと楽に楽しくなる。 設計原則の会得は、ソフトウェア設計の免許皆伝、達人への道であり、ここぞという時の、銀の弾丸になる。 モジュール化 たぶん、これが、いちばん基本の設計原則。 デザインパターンも、アナリシスパターンも、アーキテクチャパターンも、モジュール化原則の適用例になっていると思う。 モジュール化の原則違反の典型例は、一枚岩（モノシリック）で巨大なソフトウェア。 別名、密結合、スパゲティコード。 こういうソフトウェアは、理解しがたく、変更が恐ろしく難しい。 バグがあちこちに隠れていて、副作用が怖く、とてもじゃないが、コードを変更する勇気（度胸？）はない。 「一枚岩」は
継続してコードを書くということ
この度、githubへの一年間連続コミットを達成していたらしいことを確認しました。途中から平日、仕事の分も混ざっているのですが、プライベートでのコミットは毎日確認していたので、ちゃんと一年間継続できているはずです。 当初はどういうものを開発するのか定まっていなかったり、謎の練習コードばっか産まないか心配だったのですが、継続してコミットを続けていくことで、徐々に目的意識を持ってコードを書くのにも慣れてきました。 そこで、この一年でどういう考えで開発過程をたどってきたか、どういうものを開発してきたか、これからどうしたいかについて書こうと思います。 どういう考えで開発過程をたどってきたか最初は継続性のみを重視１年前と今とでは、コードを書き始める時の意識も少し変わったなと、今は思います。 １年前はどんな形であれ継続できるようにコードを書いて、たまにdotfilesいじったりとか、遅くに会社を出ると
混乱しがちなサービスという概念について - かとじゅんの技術日誌
社内でサービスがよくわからないという話になったので、考察を少しまとめておきます。 過去のエントリでも以下のように触れましたが、もう少しかみ砕いてみよう。 サービスという言葉はあいまい まず、簡単に前提の整理から。単に"サービス"って言葉が何を指すのか結構曖昧です。 サービスは簡単にいうと手続きとか振る舞いのことですが、細かくいうと、PofEAAでいうサービスと、DDDいうサービスは、目的が異なります。前者はアプリケーションのためにドメインモデルを再利用可能にするためのものです。後者はドメインの知識を表している振る舞いです。これはのちほど詳しく説明します。 まぁこのあたりは具体例がないと理解しがたいですが、レイヤーの違いによって責務が異なるという感じです。DDDのサービスの章では、サービスには、アプリケーション層、ドメイン層、インフラストラクチャ層と、複数のレイヤーに存在すると言及されていま
DRYと不当な抽象化によるコストについて | POSTD
本記事は、もう随分と長い間、私がToDoリストに記したままになっていたものです。ですが今日だけは、その考えを実行に移すエネルギーと時間があったようです。私は今、少し前に最初の記事を投稿した時と同じカフェにいます。たまたまなのか、それとも……。店員が私に出した飲み物に何か入れていたに違いありません。 ベストプラクティスにならえ、という古き良きアドバイスがありますよね。そうした情報は常に耳に入ってきます。私たちは、どういうわけかテクニカルな会話の中で DRY とか KISS といった頭字語を第一の原則としてきました。熱心に、まずそうした概念に従っています。たまたま、知識欲があるために、あるいは知識がなかったために、そうした概念から外れたことをする人がいようものなら、確実にその人に嵐のような批判を浴びせます。この原則にとらわれすぎていて、そこに背を向けることを拒んでいるのです。 念のためですが、
エッ、今さら！？練習問題と具体的コード例によるTDD超入門。 - paiza times
Photo by Menlo Innovations こんにちは、今回はpaiza開発担当の佐藤がお送りします。 先月からpaizaではLeaning機能が公開されておりますが、皆さん挑戦してみて頂けたでしょうか？解くと★マークが溜まっていく、というちょっとした遊び心もあります。このゲームっぽい流れは今後もうちょっと強化されるかもしれませんので、楽しみにしていて下さい。 さて今回のブログではpaizaの練習問題（paiza Learning）を題材に、いまさらでは有りますがRSpecを使いテスト駆動*1で解いてみる、というちょっと変わったことをやってみたいと思います。※最後にJUnitのコードも有ります。 すでにTDDで開発している場合は良いのですが、これから新たにテスト駆動をやってみようという場合に、いきなり業務の中で試してみる訳にも行かず、かといって何から取り組もうかと悩んでしまったり
CodeIQについてのお知らせ
2018年4月25日をもちまして、 『CodeIQ』のプログラミング腕試しサービス、年収確約スカウトサービスは、 ITエンジニアのための年収確約スカウトサービス『moffers by CodeIQ』https://moffers.jp/ へ一本化いたしました。 これまで多くのITエンジニアの方に『CodeIQ』をご利用いただきまして、 改めて心より深く御礼申し上げます。 また、エンジニアのためのWebマガジン「CodeIQ MAGAZINE」は、 リクナビNEXTジャーナル( https://next.rikunabi.com/journal/ )に一部の記事の移行を予定しております。 今後は『moffers by CodeIQ』にて、 ITエンジニアの皆様のより良い転職をサポートするために、より一層努めてまいりますので、 引き続きご愛顧のほど何卒よろしくお願い申し上げます。 また、Cod
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
可視化法学