月別: December 2015

Software Development’s Fountain of Youth

You can view software development as being very similar to any other highly mechanized process designed to build things. Rather like a factory with all of the interrelated processes that go into making the final product. Like any manufacturing process, the software development life cycle starts with analysis and requirements and then moves on to […]


Don’t Let Your Emails Bounce Back!

  When was the last time one of your emails bounced back – Perhaps yesterday or maybe even in the last hour? In a world where email has obviously become a crucial communication channel, the lack of email validation and verification in customer email lists can be a major hurdle for your company. This is […]


Letting Your Data Quality Software Understand Your Data

  When profiling your data, sometimes you just don’t know which columns you should look into or what you should validate in them. How much would it help if your data profiling software understood your data and helped you select the relevant quality indicators? This is exactly what the new Talend 6 semantic wizard is […]


Spoiler Alert! Talend 6.1 Hits the ‘Big Screen’

Back in September I talked about how excited I was about the new Star Wars movie coming out. Well, that day is upon us. Yes, Thursday, Dec 17, is the pre-ordained day in my part of the world (Ireland).  Have you ever been hit by a spoiler? You know, an older sister who breaks the news about […]


When it Comes To Big Data – Speed Matters

  Talend vs Informatica – The Big Data Benchmark If you’ve spoken to a Talend sales representative or read some of my team’s marketing material, then you’ve undoubtedly heard our claims that when it comes to Big Data, Talend offers some significant speed advantages over the competition. Concerned that some folks might dismiss this content […]


What’s Next for IoT: 4 Things to Watch

What’s next for IoT? There’s no doubt that there’s a lot more “connected things” these days and that means a lot more data. Specifically, technology is moving out of the consumer’s hands and into Healthcare, Oil & Gas, Transportation, Aviation and more. The spread of smart devices and sensors creates new forms of value and […]


Talendの「ジョブ設計パターン」とベストプラクティス

  Talend開発者が、経験が浅かろうが豊富であろうが共通して直面することが多いのが、「このジョブを記述する最善の方法は何か」という疑問です。  効率的で、読みやすく、記述しやすく、何よりも(ほとんどの場合)維持しやすいものであるべきなのは当然です。 また、Talend Studioという自由形式の「キャンバス」では、コンポーネント、リポジトリーオブジェクト、メタデータ、及びリンケージオプションの包括的で多彩なパレットを使用してコードを「描画」できることもわかります。  では、ベストプラクティスを使用してジョブ設計を作成したことを、どのように確認したらよいのでしょうか。 ジョブ設計パターン Talendを使い始めたバージョン3.4以降、ジョブ設計は私にとって非常に重要でした。 最初は、ジョブの開発でパターンを考慮することはありませんでした。それ以前からMicrosoft SSIS等のツールを使用していたので、Talendのようなビジュアルエディターには馴染んでいました。 パターンに焦点を当てる代わりに、基本的な機能、コードの再利用性、次にキャンバスのレイアウト、そして最後に命名規則に注目していました。 しかし、さまざまなユースケース向けに数百のTalendジョブを開発し、コードがより洗練されて再利用性や一貫性も向上したことから、一定のパターンが浮かび上がってきました。 今年1月にTalendに入社して以来、顧客が開発したジョブを目にする機会に多く恵まれました。その結果、全ての開発者にとって、それぞれのユースケースに複数のソリューションがあるという認識に確信を持ちました。  このことが、開発者の多くにとっての問題となっているようです。  私たち開発者は同じような考え方をしますが、自分のやり方が特定のジョブを開発するうえで最善であると思い込みがちです。一方で、さらに良い方法が存在する可能性に薄々気が付いてもいます。 そこで、ベストプラクティスが必要となり、この場合はジョブ設計パターンを探すことになります。 基本的指針の明確化 可能な限り最善のジョブコードを実現するために必要なことを考えるときには、常に基本的指針が適用されます。この指針は、長年にわたるミスと成功に基づく改善の積み重ねから生まれたものです。  これはコード構築の強固な基盤となり、(私見ですが)ないがしろにしてはならない重要な原則であり、次の事柄が含まれます(順序は問いません)。 – 読み取りやすさ:簡単に把握し、理解できるコードを作成する – 記述しやすさ:最短期間に平易で単純なコードを作成する – 維持性:変更の影響を最小限に抑えて適度な複雑さを組み込む – 機能:要件を満たすコードを作成する – 再利用性:共有可能なオブジェクトと小さな作業単位を作成する – 整合性:チーム、プロジェクト、リポジトリー、コードにわたる実質的な規範を作成する – 柔軟性:曲げることはできても折れることのないコードを作成する – 拡張性:要求に応じてスループットを調整する弾力のあるモジュールを作成する – 一貫性:全てにわたる共通性を作り出す – 効率:最適化されたデータフローとコンポーネント利用を作り出す – 区画化:単一の目的に対応する、焦点を絞った小さなモジュールを作成する – 最適化:最小限のコードで最大限の機能を作り出す – パフォーマンス:最速のスループットを生む効果的なモジュールを作成する これらの指針全体で実質的なバランスをとることが重要です。特に最初の3項目は常に相反するため、調整が欠かせません。 2つの項目を満たして3つ目を犠牲してしまうことはよくあります。 できるだけ重要度に基づいて順序付けるようにします。 (基準ではなく)規範としてのガイドライン 実際にジョブ設計パターンの検討に入る前に、前述した基本的指針と併せて、考慮すべきいくつかの詳細事項について確認しておきましょう。  設定されている基準に想定外の状況に対処する余地がなく、融通が利かないために、支障が出ることがしばしばあります。  また逆に、基本的に同じことをしている複数の開発者が、弾力性がなく不合理で矛盾するコードを作成したり、さらには支離滅裂な計画されない無秩序状態を広げたりすることが頻繁に起こっています。 率直に言って、これはずさんで見当違いなことであり、容易に回避できます。 このため、まず「基準」ではなく「ガイドライン」を作成して文書化することをお勧めします。  ガイドラインは基本的指針を取り上げるものとし、それに具体的詳細を追加します。 「開発ガイドライン」文書が作成され、SDLC (ソフトウェア開発ライフサイクル)プロセスに関与する全てのチームによって採用されると、この基盤が構造、定義、及びコンテキストをサポートします。この基盤構築に取り組むことにより、長期的には誰もが満足する結果を得ることができます。 以下に提案する概要をご利用ください(あくまでもガイドラインなので、自由に変更/拡張できます)。 方法論:構築の「方法」を詳細に説明 […]


IT stuff for free! – 3 Zero-Cost Integration Projects

According to Gartner forecasts, IT spend is likely to be close to $4 trillion in 2015. It’s probably very welcoming then to hear that you can still complete some IT projects for free. Case in point: Data Integration. There are free open solutions available that are a great alternative to either hand coding all your […]