Software Development

Memilih Platform Untuk Development

Posted on Updated on

Menurut saya ada 3 platform yang pantas untuk mendapatkan perhatian untuk pengembangan aplikasi sekarang ini yaitu ASP.Net MVC, Ruby on Rails(RoR) dan Laravel (PHP). Mengapa saya memilih 3 platform tersebut salah satunya adalah kemiripan yang hampir 90%. Walaupun syntaknya beda tetapi rasanya sama.

Masing-masing memiliki kelebihan masing-masing, tetapi jika anda seorang product manager dan harus memilih salah satu untuk pengembangan. mungkin pertimbangan-pertimbangan berikut ini bisa menjadi acuan yaitu biaya, waktu dan ketersediaan sumber daya manusia yang ada. karena ke-3 hal tersebut yang menjadi kunci kualitas yang akan dihasilkan.

Asp.net mvc
jika proyek anda ingin memaksimalkan dari produk-produk Microsoft lainnya, asp.net mvc adalah pilihan yang tepat. dari segi waktu dan kualitas, asp.net mvc adalah termasuk yang terbaik. Asp.net mvc + visual studio adalah alat dengan produktivitas yang tinggi, ditambah third party control yang tersedia banyak dipasaran yang bisa menjadikan nilai tambah bagi produk anda. SDMnya cukup dipasaran kelemahannya adalah memerlukan biaya yang lebih besar dari platform lainnya.

Ruby on rails
ini adalah embahnya MVC, tidak usah diragukan lagi kualitasnya. Untuk produktifitasnya sangat tinggi di support dengan komunitas yang luas. Ror bisa jalan disemua platform, yang menjadi perhatiannya mungkin ketersediaan SDM dipasaran sehingga mungkin harganya lebih tinggi. Sebelumnya mengembangkan teliti dulu kesiapan SDM yang ada.

Laravel
Salah satu kelebihan dan kelemahan PHP adalah kemudahannya, sehingga mudah terjebak dengan “perilaku buruk”. Laravel adalah satu framework yang mengadopsi cara ala Rails di lingkungan PHP. Kekurangannya mungkin karena masih tergolong baru komponen-komponen masih kalah dibandingkan dengan Ror tetapi framework ini layak dicoba.

Kesimpulan
kesimpulannya tidak ada pemenang karena semuanya bagus.Tinggal sekarang hitung ulang, berapa nilai proyek anda. berapa untuk biaya produksi, biaya gaji dan operasional, ketersediaan SDM. Anda ingin profit margin berapa?

 

Iklan

How do I “think in AngularJS” if I have a jQuery background?

Posted on

1. Don’t design your page, and then change it with DOM manipulations

In jQuery, you design a page, and then you make it dynamic. This is because jQuery was designed for augmentation and has grown incredibly from that simple premise.

But in AngularJS, you must start from the ground up with your architecture in mind. Instead of starting by thinking “I have this piece of the DOM and I want to make it do X”, you have to start with what you want to accomplish, then go about designing your application, and then finally go about designing your view.

2. Don’t augment jQuery with AngularJS

Similarly, don’t start with the idea that jQuery does X, Y, and Z, so I’ll just add AngularJS on top of that for models and controllers. This is really tempting when you’re just starting out, which is why I always recommend that new AngularJS developers don’t use jQuery at all, at least until they get used to doing things the “Angular Way”.

I’ve seen many developers here and on the mailing list create these elaborate solutions with jQuery plugins of 150 or 200 lines of code that they then glue into AngularJS with a collection of callbacks and$applys that are confusing and convoluted; but they eventually get it working! The problem is that inmost cases that jQuery plugin could be rewritten in AngularJS in a fraction of the code, where suddenly everything becomes comprehensible and straightforward.

The bottom line is this: when solutioning, first “think in AngularJS”; if you can’t think of a solution, ask the community; if after all of that there is no easy solution, then feel free to reach for the jQuery. But don’t let jQuery become a crutch or you’ll never master AngularJS.

3. Always think in terms of architecture

First know that single-page applications are applications. They’re not webpages. So we need to think like a server-side developer in addition to thinking like a client-side developer. We have to think about how to divide our application into individual, extensible, testable components.

So then how do you do that? How do you “think in AngularJS”? Here are some general principles, contrasted with jQuery.

The view is the “official record”

In jQuery, we programmatically change the view. We could have a dropdown menu defined as a ullike so:

<ul class="main-menu">
    <li class="active">
        <a href="#/home">Home</a>
    </li>
    <li>
        <a href="#/menu1">Menu 1</a>
        <ul>
            <li><a href="#/sm1">Submenu 1</a></li>
            <li><a href="#/sm2">Submenu 2</a></li>
            <li><a href="#/sm3">Submenu 3</a></li>
        </ul>
    </li>
    <li>
        <a href="#/home">Menu 2</a>
    </li>
</ul>

In jQuery, in our application logic, we would activate it with something like:

$('.main-menu').dropdownMenu();

When we just look at the view, it’s not immediately obvious that there is any functionality here. For small applications, that’s fine. But for non-trivial applications, things quickly get confusing and hard to maintain.

In AngularJS, though, the view is the official record of view-based functionality. Our ul declaration would look like this instead:

<ul class="main-menu" dropdown-menu>
    ...
</ul>

These two do the same thing, but in the AngularJS version anyone looking at the template knows what’s supposed to happen. Whenever a new member of the development team comes on board, she can look at this and then know that there is a directive called dropdownMenu operating on it; she doesn’t need to intuit the right answer or sift through any code. The view told us what was supposed to happen. Much cleaner.

Developers new to AngularJS often ask a question like: how do I find all links of a specific kind and add a directive onto them. The developer is always flabbergasted when we reply: you don’t. But the reason you don’t do that is that this is like half-jQuery, half-AngularJS, and no good. The problem here is that the developer is trying to “do jQuery” in the context of AngularJS. That’s never going to work well. The view is the official record. Outside of a directive (more on this below), you never, ever, never change the DOM. And directives are applied in the view, so intent is clear.

Remember: don’t design, and then mark up. You must architect, and then design.

Data binding

This is by far one of the most awesome features of AngularJS and cuts out a lot of the need to do the kinds of DOM manipulations I mentioned in the previous section. AngularJS will automatically update your view so you don’t have to! In jQuery, we respond to events and then update content. Something like:

$.ajax({
  url: '/myEndpoint.json',
  success: function ( data, status ) {
    $('ul#log').append('<li>Data Received!</li>');
  }
});

For a view that looks like this:

<ul class="messages" id="log">
</ul>

Apart from mixing concerns, we also have the same problems of signifying intent that I mentioned before. But more importantly, we had to manually reference and update a DOM node. And if we want to delete a log entry, we have to code against the DOM for that too. How do we test the logic apart from the DOM? And what if we want to change the presentation?

This a little messy and a trifle frail. But in AngularJS, we can do this:

$http( '/myEndpoint.json' ).then( function ( response ) {
    $scope.log.push( { msg: 'Data Received!' } );
});

And our view can look like this:

<ul class="messages">
    <li ng-repeat="entry in log">{{ entry.msg }}</li>
</ul>

But for that matter, our view could look like this:

<div class="messages">
    <div class="alert" ng-repeat="entry in log">
        {{ entry.msg }}
    </div>
</div>

And now instead of using an unordered list, we’re using Bootstrap alert boxes. And we never had to change the controller code! But more importantly, no matter where or how the log gets updated, the view will change too. Automatically. Neat!

Though I didn’t show it here, the data binding is two-way. So those log messages could also be editable in the view just by doing this: <input ng-model="entry.msg" />. And there was much rejoicing.

Distinct model layer

In jQuery, the DOM is kind of like the model. But in AngularJS, we have a separate model layer that we can manage in any way we want, completely independently from the view. This helps for the above data binding, maintains separation of concerns, and introduces far greater testability. Other answers mentioned this point, so I’ll just leave it at that.

Separation of concerns

And all of the above tie into this over-arching theme: keep your concerns separate. Your view acts as the official record of what is supposed to happen (for the most part); your model represents your data; you have a service layer to perform reusable tasks; you do DOM manipulation and augment your view with directives; and you glue it all together with controllers. This was also mentioned in other answers, and the only thing I would add pertains to testability, which I discuss in another section below.

Dependency injection

To help us out with separation of concerns is dependency injection (DI). If you come from a server-side language (from Java to PHP) you’re probably familiar with this concept already, but if you’re a client-side guy coming from jQuery, this concept can seem anything from silly to superfluous to hipster. But it’s not. 🙂

From a broad perspective, DI means that you can declare components very freely and then from any other component, just ask for an instance of it and it will be granted. You don’t have to know about loading order, or file locations, or anything like that. The power may not immediately be visible, but I’ll provide just one (common) example: testing.

Let’s say in our application, we require a service that implements server-side storage through a RESTAPI and, depending on application state, local storage as well. When running tests on our controllers, we don’t want to have to communicate with the server – we’re testing the controller, after all. We can just add a mock service of the same name as our original component, and the injector will ensure that our controller gets the fake one automatically – our controller doesn’t and needn’t know the difference.

Speaking of testing…

4. Test-driven development – always

This is really part of section 3 on architecture, but it’s so important that I’m putting it as its own top-level section.

Out of all of the many jQuery plugins you’ve seen, used, or written, how many of them had an accompanying test suite? Not very many because jQuery isn’t very amenable to that. But AngularJS is.

In jQuery, the only way to test is often to create the component independently with a sample/demo page against which our tests can perform DOM manipulation. So then we have to develop a component separately and then integrate it into our application. How inconvenient! So much of the time, when developing with jQuery, we opt for iterative instead of test-driven development. And who could blame us?

But because we have separation of concerns, we can do test-driven development iteratively in AngularJS! For example, let’s say we want a super-simple directive to indicate in our menu what our current route is. We can declare what we want in our view:

<a href="/hello" when-active>Hello</a>

Okay, now we can write a test:

it( 'should add "active" when the route changes', inject(function() {
    var elm = $compile( '<a href="/hello" when-active>Hello</a>' )( $scope );

    $location.path('/not-matching');
    expect( elm.hasClass('active') ).toBeFalsey();

    $location.path( '/hello' );
    expect( elm.hasClass('active') ).toBeTruthy();
}));

We run our test and confirm that it fails. So now we can write our directive:

.directive( 'whenActive', function ( $location ) {
    return {
        scope: true,
        link: function ( scope, element, attrs ) {
            scope.$on( '$routeChangeSuccess', function () {
                if ( $location.path() == element.attr( 'href' ) ) {
                    element.addClass( 'active' );
                }
                else {
                    element.removeClass( 'active' );
                }
            });
        }
    };
});

Our test now passes and our menu performs as requested. Our development is both iterative and test-driven. Wicked-cool.

5. Conceptually, directives are not packaged jQuery

You’ll often hear “only do DOM manipulation in a directive”. This is a necessity. Treat it with due deference!

But let’s dive a little deeper…

Some directives just decorate what’s already in the view (think ngClass) and therefore sometimes do DOM manipulation straight away and then are basically done. But if a directive is like a “widget” and has a template, it should also respect separation of concerns. That is, the template too should remain largely independent from its implementation in the link and controller functions.

AngularJS comes with an entire set of tools to make this very easy; with ngClass we can dynamically update the class; ngBind allows two-way data binding; ngShow and ngHide programmatically show or hide an element; and many more – including the ones we write ourselves. In other words, we can do all kinds of awesomeness without DOM manipulation. The less DOM manipulation, the easier directives are to test, the easier they are to style, the easier they are to change in the future, and the more re-usable and distributable they are.

I see lots of developers new to AngularJS using directives as the place to throw a bunch of jQuery. In other words, they think “since I can’t do DOM manipulation in the controller, I’ll take that code put it in a directive”. While that certainly is much better, it’s often still wrong.

Think of the logger we programmed in section 3. Even if we put that in a directive, we still want to do it the “Angular Way”. It still doesn’t take any DOM manipulation! There are lots of times when DOM manipulation is necessary, but it’s a lot rarer than you think! Before doing DOM manipulation anywherein your application, ask yourself if you really need to. There might be a better way.

Here’s a quick example that shows the pattern I see most frequently. We want a toggleable button. (Note: this example is a little contrived and a skosh verbose to represent more complicated cases that are solved in exactly the same way.)

.directive( 'myDirective', function () {
    return {
        template: '<a>Toggle me!</a>',
        link: function ( scope, element, attrs ) {
            var on = false;

            $(element).click( function () {
                if ( on ) {
                    $(element).removeClass( 'active' );
                }
                else {
                    $(element).addClass( 'active' );
                }

                on = !on;
            });
        }
    };
});

There are a few things wrong with this. First, jQuery was never necessary. There’s nothing we did here that needed jQuery at all! Second, even if we already have jQuery on our page, there’s no reason to use it here; we can simply use angular.element and our component will still work when dropped into a project that doesn’t have jQuery. Third, even assuming jQuery was required for this directive to work, jqLite (angular.element) will always use jQuery if it was loaded! So we needn’t use the $ – we can just use angular.element. Fourth, closely related to the third, is that jqLite elements needn’t be wrapped in $ – the element that is passed to the link function would already be a jQuery element! And fifth, which we’ve mentioned in previous sections, why are we mixing template stuff into our logic?

This directive can be rewritten (even for very complicated cases!) much more simply like so:

.directive( 'myDirective', function () {
    return {
        scope: true,
        template: '<a ng-class="{active: on}" ng-click="toggle()">Toggle me!</a>',
        link: function ( scope, element, attrs ) {
            scope.on = false;

            scope.toggle = function () {
                scope.on = !scope.on;
            };
        }
    };
});

Again, the template stuff is in the template, so you (or your users) can easily swap it out for one that meets any style necessary, and the logic never had to be touched. Reusability – boom!

And there are still all those other benefits, like testing – it’s easy! No matter what’s in the template, the directive’s internal API is never touched, so refactoring is easy. You can change the template as much as you want without touching the directive. And no matter what you change, your tests still pass.

w00t!

So if directives aren’t just collections of jQuery-like functions, what are they? Directives are actuallyextensions of HTML. If HTML doesn’t do something you need it to do, you write a directive to do it for you, and then use it just as if it was part of HTML.

Put another way, if AngularJS doesn’t do something out of the box, think how the team would accomplish it to fit right in with ngClickngClass, et al.

Summary

Don’t even use jQuery. Don’t even include it. It will hold you back. And when you come to a problem that you think you know how to solve in jQuery already, before you reach for the $, try to think about how to do it within the confines the AngularJS. If you don’t know, ask! 19 times out of 20, the best way to do it doesn’t need jQuery and to try to solve it with jQuery results in more work for you.

sumber : http://stackoverflow.com/questions/14994391/how-do-i-think-in-angularjs-if-i-have-a-jquery-background?rq=1

Zen Koding (1)

Posted on Updated on

Dahulu kala hiduplah seorang mantan pendekar, sehari-hari kegiatannya selain melatih kungfu, semedi dan ada juga kegiatan lain yaitu koding. Koding?ya benar. Ini adalah percakapan sang guru dengan salah satu muridnya yang tertarik kedunia pemrograman.
Murid :“Guru!..susah mana, belajar beladiri dengan pemrograman”

Guru :”Sama-sama sulit anakku. Belajar pemrograman seperti kita belajar beladiri. Butuh ketekunan dan keseriusan.Seperti halnya belajar beladiri, kamu tidak bisa sekali atau dua kali latihan terus jadi jago berkelahi”.
Murid :”Terus..apa yang harus aku lakukan untuk belajar pemrograman?”
Guru : “Sama halnya juga belajar kungfu muridku. Kamu harus belajar kihon (latihan dasar), bagaimana kuda-kuda yang baik. Latihan memukul, menendang,menangkis.Setelah itu kamu bisa berlatih Ken (jurus)”.
Murid : “Apa kihon yang harus saya pelajari guru?”.
Guru:”Kihon dipemrograman ada 3 yaitu pendifinisian variable,percabangan dan perulangan. Ini berlaku ke semua bahasa pemrograman”.
Murid:”Pendifinisian variable..apa itu guru?”
Guru : “Pendifinisian variable adalah dasar dari segala dasar di dunia pemrograman. Pada dasarnya ada 2 jenis variable yaitu string dan numeric. String mewakili huruf atau abjad sedangkan numeric mewakili angka. Cuma untuk proses efesinsi dan memudahkan numeric dibagi lagi menjadi beberapa jenis. Ada yang namanya integer yang mewakili bilangan bulat, ada juga float yang mewakili bilangan pecahan. Ada juga double untuk bilangan integer yang lebih besar.Masing-masing bahasa mempunyai nama dan jenis yang beda. Pastikan kamu membaca kitabnya di bab variable”

Murid : “Kalau String sendiri ada pembagiannya tidak guru?”

Guru : “String sendiri ada 2, yaitu string sendiri, yang mewakili satu untaian kalimat dan ada yang namanya char yang mewakili karakter atau abjad.Jangan lupa. Kamu harus belajar menggunakan string. Seperti cara menggabungkan string, mengambil sejumlah string di posisi tertentu.”

Murid:”Ada hal-hal lain yang harus saya pelajari di bab pendifinisain variable?”
Guru :”Masih ada muridku. Kamu harus belajar konsep Array yaitu variable yang disusun berdasarkan urutan indek. Dibahasa pemrograman yang modern sekarang ada juga yang namanya Collection.Kamu harus belajar itu juga.Oh ya, kamu harus bisa juga melakukan proses matematik seperti perkalian,pembagian atau penggurangan dengan tipe data numeric”.

Murid : “Untuk kihon percabangan dan perulangan gimana penjelasannya guru?”

Guru :”Percabangan adalah proses menentukan suatu keputusan terhadap pilihan. Misalnya kalau hasil nya A maka dia akan ke proses B sedangkan kalau hasilnya C maka yang di pilih adalah D. Sintaknya biasanya dengan kalimat IF … THEN .. ELSE…. Pilihan tidak hanya 2 buah bisa berapa saja. Karena itu kamu juga harus berlatih IF Bersarang. Sekalian itu ada juga SWITCH. Kata Switch lebih mudah digunakan untuk pilihan yang lebih dari 2″.

Murid:”Kalau perulangan, gimana penjelasannya guru..”

Guru : Perulangan sangat diperlukan jika ingin mengeksekusi baris kode berkali-kali. Misalnya kita ingin menuliskan kata “Halo!” 100 kali. Maka kita tidak perlu menuliskann 100x tetapi cukup sintak For 1 To 100 kemudian tulis kata “Halo!”. Ini juga setiap bahasa pemrograman mempunyai sintak sendiri-sendiri.Ada juga While..DO. Sintak ini untuk melakukan perulangan untuk jumlah perulangan yang tidak kita ketahui. Misalnya kita melakukan perulangan sampai hasil yang kita ingin benar, sesuai yang kita harapkan.

Murid :”Terima kasih penjelasannya guru, apakah dengan pengetahuan itu saya bisa langsung membuat program”.

Guru:”Seperti kataku tadi, koding itu seperi berlatih beladiri.kuncinya adalah berlatih dan berlatih….”

Murid:”Kalo pemrograman berorientasi object itu apa guru”.

Guru:”amitabha…saya akan menjelaskan pemrograman berorientasi object setelah kamu selesai melakukan latihan dasarnya. Ambilah salah satu kitab bahasa pemrograman dan berlatihlah dengan tekun”.

Lalu sang murid pergi ke perpustakaan perguruan untuk meminjam kitab bahasa pemrograman, setelah itu pergi ke Mall untuk kredit laptop dan modem GSM untuk menemani semedinya.(Bersambung…)

Membuat data bisa ngomong

Posted on Updated on

Sering saya melihat aplikasi-aplikasi seperti ini. Data yang ribuan/ratusan ditampilkan dalam 1 layar. Benarkan? Jika saya seorang pengguna dan disuguhi data sebanyak itu, pikiran pertama saya adalah buat apa data ini dan bagaimana saya membacanya.Data sebanyak itu jika ditampilkan malah kontra produktif alias tidak berarti. Saya teringat teman sekerja dulu yang dimarahi seorang Vice Presiden gara-gara disuguhi data yang berlembar-lembar dan cuma ngomong tolong diringkas dan maksimal 2 lembar saja.Kita harus belajar dan mencari tahu siapa yang mengkonsumsi laporan kita

Penyajian data yang sangat banyak walaupun disertai informasi yang akurat sangatlah tidak efektif. Tidak hanya untuk user yang membacanya tetapi juga dari segi teknis. Pernah saya mendengar teman yang butuh grid baru karena grid yang dipakai sekarang sangat lambat karena datanya sudah mencapai 1 jutaan record. Atau waktu untuk loading untuk menampilkan data semakin lama semakin lambat, kalo ini saya yang mengalami sendiri.he3. Penyajian data harus seperti penyajian makanan, makanannya lezat wadahnya pas tentu semakain sedaaapp…

Bagaimana memaksa data bisa ngomong?
Sebenarnya tidak salah jika anda menampilkan seluruh data customer anda. Paling tidak, kita dapat melihat jumlah customer kita. Alangkah baiknya juga disertai karakteristik atau demografi dari customer kita. Ini akan sangat membantu dalam menentukan segmen pasar yang akan diraih atau sebagai bahan marketing atau pemilihan product yang akan dijual.

grafik report top customer

Jika aplikasi anda sudah dapat menampilkan 10 customer dengan pembelian paling terbanyak dan 10 Produk yang paling laris, apa yang kurang? Sebenarnya sudah bagus dapat menampilkannya dan data anda sudah dapat ngomong. Cuma omongan masa lalu.Iya kan?. 10 customer paling atas dan 10 produk paling atas adalah rekaman kejadian masa lalu. Artinya telah terjadi penjualan yang menghasilkan laporan tadi. Tapi tidak dapat menjelaskan mengapa si A menjadi orang dengan pembelian paling atas, atau produk B menjadi paling laris. Adakah korelasinya dengan demografi customer kita. Yes! Saatnya membuat data kita bisa ngoceh…..!!!

Selamat datang di Business Intelligent!

Apa itu business Intelligent, kalo dari pengertiannya adalah sebagai berikut dari (diambil dari istilah dari pengertian BI di SQL Server 2008).

Business intelligence solutions include effective storage and presentation of key enterprise data so that authorized users can quickly and easily access and interpret it. The BI tools in SQL Server 2008 allow enterprises to manage their business at a new level, whether to understand why a particular venture got the results it did, to decide on courses of action based on past data, or to accurately forecast future
results on the basis of historical data.

Yang perlu digarisbawahi disini adalah kalimat based on past data dan forecast future
Results
. Jadi tidak hanya dapat ngomong yang sudah-sudah tetapi juga memprediksi kejadian yang akan datang berdasarkan data-data sekarang.

Berikut ini tool-tool yang biasanya ada untuk mengelola Business Intelligent,

1. Naïve Bayes Algorithm
Dengan Naïve Bayes Algorithm memungkinkan kita memprediksi kemungkinan kejadian didepan dengan data-data yang ada sekarang. Contohnya kemungkinan seorang customer membeli produk A berdasarkan tingkat pendidikan, jumlah anak, penghasilan dan lain-lainnya. Atau kalo contoh gambar dibawah ini adalah penggunaan Naïve Bayes Algorithm untuk memprediksi kemungkinan terwakilinya di parlemen Amerika, apakah dari Demokrat atau Republik berdasarkan keperpihakan suara pada tiap-tiap isu yang diusung.


contoh aplikasi menggunakan algoritma Naïve Bayes

2. Decision Trees Algorithm
Bayangkan anda seorang pegawai Bank di bagian kredit. Ada calon nasabah yang secara tampang kurang meyakinkan. kemudian anda mewawancarainya.Apakah anda sudah menikah?ia jawab ya. Apakah anda sudah bekerja?Ia menjawab sudah dengan lama bekerja 3 tahun. Berapa penghasilan anda sebulan ?ia jawab antara 10-12 juta berbulan.tetapi ternyata orang tersebut mempunyai record jelek yaitu pernah tidak membayar kredit selama 3 bulan berturut-turut di periode sebelumnya.Pertanyaan apakah orang tersebut permohonan kreditnya di kabulkan?
Dengan Decision Trees Algorithm memungkinkan memecahkan teka-teki tersebut.

Contoh aplikasi menggunakan algoritma decition tree

3. Time Series Algorithm
Jika anda mengelola toko retail kebutuhan pokok mungkin akan mengalami kejadian seperti ini. Tiap tanggal muda, ada peningkatan pembelian kebutuhan pokok. Jika menjelang hari raya, akan lebih meningkatnya lagi. Akibatnya anda harus memprediksi kira-kira berapa stock yang harus tersedia. Dari kejadian tersebut sebenarnya anda sedang melakukan analisa time series, yaitu menggunakan riwayat penjualan masa lalu untuk memperkirakan jumlah stock dimasa datang.

4. Clustering
Clustering sangat membantu mengelompokan data-data dengan parameter yang tidak jelas. Seperti contohnya begini. Anda mengelola rental persewaan DVD/VCD. Ada bermacam-macam pelanggan, ada yang suka film action,romantic,komedi atau documenter.Atau ada juga yang suka lebih dari satu genre. Dengan bantuan algoritma Clustering memungkian semua data dikelompokan berdasarkan riwayat transaksinya.

5. Sequence Clustering
Sequence Clustering dirancang untuk menganalisis populasi yang berasal dari data/kejadian ya ng berurutan dalam kelompok kasus yang sama atau tidak. Seperti contohnya untuk menganalisa customer purchase analysis dan bioinformatics.

6. Neural Network and Logistic Regression
Algoritma ini adalah salah satu yang terkenal di bidang kecerdasan buatan yaitu bagaimana memecahkan masalah dengan meniru jaringan saraf otak kita.

Contoh penggunaan algoritma Neural Network

Sebenarnya ada algoritma-algoritma lainnya yang dapat membuat aplikasi kita tambah yahud..yaitu Fuzzy Logic,AHP (Analytic Hierarchy Process) untuk membantu mengambil keputusan dengan masalah yang komplek. Dan satu lagi yang ini pasti kita sudah tahu semua yaitu Statistik.

OK!Sudah saatnya aplikasi anda tidak boleh dibilang cuma memindahkan kertas ke komputer!

Inilah cerita sebenarnya tentang software development…

Posted on

Aku gak ngerti kok bisa berfikiran seperti dibawah ini,awalnya ketika bergabung ke sebuah milis tentang management proyek IT, cerita banyaknya tantangan yang mereka hadapi dilapangan, keluh kesah mereka selama proyek . Hampir semuanya pernah saya hadapi.

Akhirnya aku merasa bahwa bisnis software development sendiri masih sebuah misteri tersendiri, banyak yang sukses tetapi saya yakin lebih banyak lagi yang tidak sukses.

1. Software development seperti proses pemanggilan arwah
Dibandingkan dengan project lainnya seperti proyek sipil misalnya, proyek IT adalah proyek ilmu gaib. Kita harus memindahkan isi kepala seorang akuntan ke program kita. Pengalaman mereka yang bertahun-tahun harus kita rumuskan, kita koding tidak boleh dari 3 bulan. Tugas kita adalah membuat benda mati yang bernama computer harus hidup dan pintar (kadang harus lebih pintar dari seorang akuntan tersebut). Masih mending proyek sipil, seumpama kita membangun jembatan, semua orang dapat melihat bentuk jembatan tadi . Kalo ada kesalahan semua bisa membantu memberitahu.

2. Bisnis software itu seperti orang yang kecanduan togel.
4 dari 10 orang terkaya didunia adalah bisnis di dunia IT yaitu pemilik Microsoft,Oracle,Dell. Belum lagi kisah keberhasilan google,facebook, tweeter ,yahoo, Amazon,eBay yang membuat pendirinya menjadi milyuner-milyuner baru . Atau perusahaan-perusahaan IT di India yang berhasil menyumbang pendapatan negaranya secara cukup significant. Tidak dipungkiri hal tersebut menjadi magnet atau perhatian semua orang untuk menekuninya, atau paling tidak mencoba berkarir dibidang IT.
Bisnis IT memang menyediakan mimpi-mimpi indah,tetapi banyak orang-orang yang tidak dapat membedakan dengan kenyataan aslinya. Bisnis IT adalah bisnis nilai tambah alias bisnis jasa.Perlu kreatiitas tinggi dan kemampuan membaca peluang usaha. Untuk software development sendiri sudah sanngat-sangat-sangat (3x) berubah!! Kita tidak bisa lagi mengandalkan membuat software terus bilang ini “ini aku mau jual software xxx harganya segini”. Mengapa? Keahlian membuat software bukan barang langka lagi sekarang. Anak-anak smp atau sma saya lihat sudah banyak yang mahir menulis kode. Free software banyak, open source juga banyak
Jadi bagaimana mengatasinya? Salah satunya jadilah “Pemanggil arwah yang bagus”, ini yang membedakan dengan para penulis kode. Mereka yang jago menulis kode belum tentu jago membuat program. Alias jago membuat kode tidak sama dengan membuat program. Atau sama saja yang jago main gitar belum tentu jago membuat lagu.
Satu lagi! kesuksesan Google,Amazon,eBay,Facebook bukan karena menjual software seperti yang dilakukan oleh Microsoft,Oracle,Sun atau Borland. Mereka sukses karena mampu menggaet user dalam jumlah yang besar, menjadi framework berkomunikasi atau beraktifitas.Ini yang saya maksud pergeseran nilai di bisnis ini. Maka jika anda tidak dapat mengikuti perkembangan ini maka kemungkinan anda termasuk orang-orang yang seperti kecanduan togel. Mengapa?kalo kita lihat apa sih alasan orang-orang membeli togel? Untung?nanti dulu, saya yakin mereka banyak ruginya. Tetapi mengapa mereka membeli terus? Sebernarnya yang mereka beli itu adalah “harapan” alias “mimpi”.

3. Bisnis software seperti bermain sinetron
Saya tidak tahu apakah terjadi juga di Negara-negara maju. Tetapi dalam “proses pemanggilan arwah” tadi kita harus ikut juga berperan juga. Sebenarnya hal ini termasuk hal yang saya sukai karena saya bisa menjadi bermacam-maca profesi yang ada. Masuk ke dalam dunia mereka dengan segala permasalahan yang mereka hadapi. Kadang harus berperan seperti seorang akuntan, sales,produksi atau seorang CEO.

4. Bisnis software seperti jualan obat.
Kita harus bisa berkoar-koar kalo software yang kita buat adalah yang terhebat dan dapat menyelesaikan semua masalah.

5. Bisnis software seperti bisnis prostitusi
Banyak cara atau methode yang berkembang di software development. Dari desain arsitektur seperti jaman jadul dulu kita mengenal yang namanya waterfall,kemudian berkembang menjadi Rational Unified, Agile dan Extreme programming. Kemudian ada Object Oriented Programming, Aspect Oriented Programming, MVC. Bermacam-macam ORM dan framework bermunculan tetapi sebenarnya intinya cuma satu yaitu membuat pelanggan puas. Oke..puaaaaaasssssssss sekarang!!!

Why Software-as-a-Service?

Posted on Updated on

Ini tentang sebuah mimpi yang dilandasi kemajuan teknologi saat ini. Teknologi berkembang pesat, merubah cara kita mengembangkan software dan akhirnya merubah pula cara kita menjual software. Kalo dulu kita membeli sebuah software seperti membeli barang sekarang kita dapat membeli software benar-benar sebagai sebuah jasa layanan. Kita membayar sesuai yang kita butuhkan saja. Hal tersebut sangat menguntungkan kedua belah pihak, mengapa? Berikut ini keuntungannya.

Better Return on Your Investment

SaaS akan memangkas biaya implementasi karena tidak memerlukan hardware baru, tidak perlu install, dan tidak perlu melibatkan IT Departement. Kalaupun melibatkan mereka hanya dalam skala kecil yang berurusan dengan jaringan internet. Menurut  dari beberapa sumber model SaaS akan memotong sampai 40% daripada model konvensional.

Rapid Implementation

Proses instalasi software boleh dikatakan gampang-gampang susah. Terkadang sering ditemui kasus dimana software yang telah dipackage tidak berjalan sesuai dengan harapan. Sangat tergantung OS yang ada dan software yang telah terinstall di PC tersebut.Dengan SaaS proses implementasi sudah tidak tergantung OS lagi Apakah PC tersebut memakai Windows (versi apa saja), Linux atau Mac. Selama ada browser dan koneksi intenet semua akan berjalan aman.

Automatic Upgrades

Ini salah satu kelebihan SaaS yaitu user selalu memakai versi terbaru. Dengan system terpusat memungkian pihak developer me-upgrade secara cepat.

Improved Security

Mengapa demikian? Server yang digunakan untuk server aplikasi dan data SaaS biasanya telah dirancang dengan baik. Bagaimana system backup datanya, (disaster recovery plan). Ini akan sangat membantu perusahaan menengah bawah yang tidak mempunyai budget IT berlebih.

Dari segi vendornys. SaaS akan memotong banyak biaya implementasi dan maintenance. Mendorong kreativitas dan inovasi yang terus menerus. Dengan model  SaaS mau tidak mau harus berusaha memberikan layanan yang terbaik setiap tahunnya jika tidak ingin ditinggalkan para customernya.

Buat saya pribadi? SaaS akan menghemat energi dan resources yang ada. Saya memimpikan dapat mengendalikan bisnis saya cukup dari atas bukit. Pendapatan Internasional tetapi hidup tetap dengan gaya tradisional.

Principles behind the Agile Manifesto

Posted on

jika Anda hanya punya Tim kecil untuk mengembangkan aplikasi, pirnsip-prinsip yang dikembangkan oleh Martin Fowler,Ken Back dan rekan-rekannya di   Agile Manifesto akan sangat mambantu

We follow these principles:

Our highest priority is to satisfy the customer
through early and continuous delivery
of valuable software.

Welcome changing requirements, even late in
development. Agile processes harness change for
the customer’s competitive advantage.

Deliver working software frequently, from a
couple of weeks to a couple of months, with a
preference to the shorter timescale.

Business people and developers must work
together daily throughout the project.

Build projects around motivated individuals.
Give them the environment and support they need,
and trust them to get the job done.

The most efficient and effective method of
conveying information to and within a development
team is face-to-face conversation.

Working software is the primary measure of progress.

Agile processes promote sustainable development.
The sponsors, developers, and users should be able
to maintain a constant pace indefinitely.

Continuous attention to technical excellence
and good design enhances agility.

Simplicity–the art of maximizing the amount
of work not done–is essential.

The best architectures, requirements, and designs
emerge from self-organizing teams.

At regular intervals, the team reflects on how
to become more effective, then tunes and adjusts
its behavior accordingly.

Sumber: :http://agilemanifesto.org/principles.html