Pemrogram Paralel pada mesin multi-core processor

Dewasa ini baik PC maupun Laptop telah menggunakan teknologi multi-core
processor. Sepertinya sampai saat ini kita belum memanfaat- kannya untuk
kebutuhan pengolahan paralel. Beberapa kemungkinan untuk pemanfaatannya
dengan menggunakan tool/library/bahasa pemrograman berikut:
1. OpenMP http://openMP.org/wp/
e-book bisa di DL di sini
Feature:
The OpenMP Application Program Interface (API) supports multi-platform
shared-memory parallel programming in C/C++ and Fortran. OpenMP is a
portable, scalable model with a simple and flexible interface for
developing parallel applications on platforms from the desktop to the
supercomputer.

2. Threading Building Block http://www.threadingbuildingblocks.org/
e-book bisa di DL di sini
Threading Building Blocks will enable you to specify parallelism far more
conveniently than using raw threads, while improving performance,
portability, and scalability.

3. Carnap Programming ( http://www.carnap.info/ )

Carnap is a general purpose programming language for the next generation
of many-core devices, many many-core systems and their applications. It
introduces a process oriented programming model that allows programmers to
separate concerns: Carnap programs consist of data structures and the
concurrent processes that act upon them.

4. StreamIt (http://www.cag.csail.mit.edu/streamit/)

StreamIt is a programming language and a compilation infrastructure,
specifically engineered for modern streaming systems. It is designed to
facilitate the programming of large streaming applications, as well as
their efficient and effective mapping to a wide variety of target
architectures, including commercial-off-the-shelf uniprocessors, multicore
architectures, and clusters of workstations.

Buku elektronik klasik (wajib) ilmu komputer

Buku elektronik (e-book) klasik, atau wajib tahu, bagi para komputer saintis dapat di download di http://e7l3.org/classics.html

Buku dikarang oleh pioner-pioner di bidang ilmu komputer antara lain:

F.E. Allen A Technological Review of the FORTRAN I Compiler 1982

Jack Crenshaw Let’s Build a Compiler 1988-1995

Edsger W. Dijkstra Notes On Structured Programming

Douglas C. Engelbar Augmenting Human Intellect: A Conceptual Framework 1962

C.A.R. Hoare Communicating Sequential Processes 1985

Brian W. Kernighan Why Pascal is Not My Favorite Programming Language

Donald E. Knuth Computer Programming as an Art 1974

W.A. Martin The MACSYMA System

John McCarthy Recursive Functions of Symbolic Expressions and their Computation by Machine (Part I) 1960, LISP 1.5 Programmer’s Manual 1962, LISP 1.5 Programmer’s Manual 1961 Draft

Dennis Ritchie The Development of the C Language* 2003

Claude Shannon A Mathematical Theory of Communication

Alan M. Turing On Computable Numbers, with an Application to the Entscheidungsproblem

Niklaus Wirth On the Design of Programming Languages

A Plea For Lean Software

Lotfi A. Zadeh From Computing with Numbers to Computing with Words—From Manipulation of Measurements to Manipulation of Perceptions 1999

Jacob Ziv and Abraham Lempel A Universal Algorithm for Sequential Data Compression

Konrad ZuseDer Plankalkül (engl.)

Digital Physics

Free on-line paper from Digital-Library Magazine

Free online paper from 1995-2006 (visit here)

From editor:

D-Lib Magazine is a solely electronic publication with a primary focus on digital library research and development, including but not limited to new technologies, applications, and contextual social and economic issues. The magazine is currently published six times a year. The full contents of the magazine, including all back issues, are available free of charge at the D-Lib web site (http://www.dlib.org) as well as multiple mirror sites around the world.

The primary goal of the magazine is timely and efficient information exchange for the digital library community. To meet this goal, both the articles and the shorter pieces are solicited or selected from among unsolicited submissions. If you would like to contribute to the D-Lib Magazine, or if you have any questions and comments about the magazine, please send e-mail to <editor@dlib.org>.

Kode Etik, Standar ISACA bagi Auditor SI dan Tabel Audit

Members and ISACA Certification holders shall:

■ Support the implementation of, and encourage compliance with, appropriate standards, procedures and controls for information systems.

■ Perform their duties with due diligence and professional care, in accordance with professional standards and best practices.

■ Serve in the interest of stakeholders in a lawful and honest manner, while maintaining high standards of conduct and character, and not engage in acts discreditable to the profession.

■ Maintain the privacy and confidentiality of information obtained in the course of their duties unless disclosure is required by legal authority. Such information shall not be used for personal benefit or released to inappropriate parties.

■ Maintain competency in their respective fields and agree to undertake only those activities, which they can reasonably expect to complete with professional competence.

■ Inform appropriate parties of the results of work performed; revealing all significant facts known to them.

■ Support the professional education of stakeholders in enhancing their understanding of information systems security and control.

RELATIONSHIP OF STANDARDS TO GUIDELINES AND PROCEDURES

IS Auditing Standards are mandatory requirements for certification holders’ reports on the audit and its findings. IS Auditing Guidelines and Procedures are detailed guidance on how to follow those standards. The IS Auditing Guidelines are guidance an IS Auditor will normally follow with the understanding that there may be situations where the auditor will not follow that guidance. In this case, it will be the IS Auditor’s responsibility to justify the way in which the work is done. The procedure examples show the steps performed by an IS Auditor and are more informative than IS Auditing Guidelines. The examples are constructed to follow the IS Auditing Standards and the IS Auditing Guidelines and provide information on following the IS Auditing Standards. To some extent, they also establish best practices for procedures to be followed.

AUDIT TABLES:

• Audit table for Application
• Audit table for Control Access
• Audit table for UNIX/LINUX Environments
• Audit table for Window XP/2000 Environments

ISACA Code of Ethics and All table could be found here

19 Langkah2 Umum Program Audit Sistem Informasi

The audit program is designed to address the primary risks of virtually all computing systems. Therefore, the objective statement and steps in the program are general by design. Obviously, computing systems can have many different applications running on them, each with its own unique set of controls. However, the controls surrounding all computing systems are very similar. The IS controls in the audit program have been grouped into four general categories:

Objective:

1. To assess the adequacy of environmental, physical security, logical security, and operational controls designed to protect IS hardware, software, and data against unauthorized access and accidental or intentional destruction or alteration, and
2. to ensure that information systems are functioning in an efficient and effective manner to help the organization achieve its strategic objectives.

TESTS OF ENVIRONMENTAL CONTROLS

Step 1. Assess the adequacy and effectiveness of the organization’s IS security policy. In addition, assess whether the control requirements specified in the organization’s IS security standards adequately protect the information assets of the organization. At a minimum, the standards should specify the following controls and require them to
be applicable to all information systems:

a. The maiden password should be changed after the system is installed.

b. There is a minimum password length of eight or more characters.

c. Passwords require a combination of alpha and numeric characters.

d. The password is masked on the screen as it is entered.

e. The password file is encrypted so nobody can read it.

f. There is a password expiration period of 60 days or less.

g. Three or fewer unsuccessful sign-on attempts are allowed, then the user ID is suspended.

h. User sessions are terminated after a specified period of inactivity (e.g., five minutes or less).

i. Concurrent sign-on sessions are not allowed.

j. Procedures are in place to remove user IDs of terminated users in a timely manner.

k. Users are trained not to share or divulge their passwords with other users, post them in their workstations, store them in eletronic files, or perform any other act that could divulge theirpasswords.

l. Unsuccessful sign-on attempts and other logical security-related events (e.g., adding and deleting users, resetting passwords, restarting the system) are logged by the system, and the log is reviewed regularly by system security staff.

m. Fully developed and tested backup and recovery procedures exist to help ensure uninterrupted business resumption in the event of a full or partial disaster.

n. New information systems are required to be designed to enable the aforementioned controls to be implemented by system security administrators. New systems include those developed in house, those purchased from vendors, and third-party processor systems. In the case of software vendors and third-party processors,the above control requirements should be specified as requirements in the contract.

Step 2. For service organization applications, examine the most recent report in the policies and procedures placed in operation at the vendor’s data processing site as prepared by its external auditors. In the United States, the format and testing requirements are dictated by Statement on Auditing Standards 70 (SAS 70), issued by the American Institute of Certified Public Accountants.

Step 3. If the system was purchased from and supported by a vendor, assess the financial stability of the system vendor using the most recent audited financial statements prepared by the vendor’s external auditors.

Step 4. Examine the vendor software license agreement and any agreements for ongoing maintenance and support to ensure that they are current, address service needs, and do not contain or omit any wording that could be detrimental to your organization.

TESTS OF PHYSICAL SECURITY CONTROLS
Step 5. Assess the adequacy of physical security over the computer system hardware and storage media.

Step 6. Determine whether an adequately trained backup system security administrator has been designated.

Step 7. Assess the adequacy and effectiveness of the written business resumption plan, including the results of mock disaster tests that have been performed.

Step 8. Assess the adequacy of insurance coverage over the hardware, operating system, application software, and data.

TESTS OF LOGICAL SECURITY CONTROLS
Step 9. Determine whether the maiden password for the system has been changed and whether controls exist to change it on a periodic basis in conformity with the computing system security policy, standards, or guidelines identified in Step 1.

Step 10. Observe the system security administrator sign on and print a list of current system users and their access capabilities. Alternatively, if you can obtain appropriate system access, you can obtain the list of users independently.

Step 11. Document and assess the reasonableness of the default system security parameter settings. The settings should conform to the organization’s computing system security policy, standards, or guidelines tested in Step 1. (Be alert to the fact that in some systems, individual user parameter settings override the default system security
parameter settings.)

Step 12. Test the functionality of the logical security controls of the system (e.g., password masking, minimum password length, password expiration, user ID suspended after successive invalid sign-on attempts, log-on times allowed, and session time-outs).

Step 13. Determine whether the file containing user passwords is encrypted and cannot be viewed by anyone, including the system security administrator.

Step 14. Determine whether sensitive data, including passwords, are adequately
encrypted throughout their life cycles, including during storage, transmission through any internal or external network or telecommunications devices, and duplication on any backup media.

Step 15. Assess the adequacy of procedures to review the log of system security-related events (e.g., successive invalid sign-on attempts, system restarts, changes to user access capabilities and user parameter settings).

Step 16. Assess the adequacy of remote access controls (e.g., virtual private networks [VPNs], token devices [CRYPTOCard, SecurID, etc.], automatic dial-back, secure sockets layer [SSL]).

TESTS OF INFORMATION SYSTEMS OPERATING CONTROLS
Step 17. Determine whether duties are adequately segregated in the operating
areas supporting the information system (e.g., transactions should be authorized only by the originating department, programmers should not have the capability to execute production programs, procedures should be adequately documented, etc.).

Step 18. Determine whether there have been any significant software problems with the system. Assess the adequacy, timeliness, and documentation of resolution efforts.

Step 19. Assess the adequacy of controls that help ensure that IS operations are functioning in an efficient and effective manner to support the strategic objectives and business operations of the organization (e.g., system operators should be monitoring CPU processing and storage capacity utilization throughout each day to ensure that adequate reserve capacities exist at all times).

more details read here (pdf)

Panduan Terpadu Menggunakan UML

Panduan Terpadu dalam “Analysis dan Design Modeling” menggunakan UML pada studi kasus “On_line Shoping“

(Maciaszek, L.A. (2001): Requirements Analysis and System Design, Developing Information System with UML, Addison Wesley)

Free paper BioComputing from PSB

The Pacific Symposium on Biocomputing (PSB) is an international, multidisciplinary conference for the presentation and discussion of current research in the theory and application of computational methods in problems of biological significance. Papers and presentations are rigorously peer reviewed and are published in an archival proceedings volume. PSB 2008 will be held January 4-8, 2008 at the Fairmont Orchid on the Big Island of Hawaii. Tutorials will be offered prior to the start of the conference.

PSB 2008 will bring together top researchers from the US, the Asian Pacific nations, and around the world to exchange research results and address open issues in all aspects of computational biology. PSB is a forum for the presentation of work in databases, algorithms, interfaces, visualization, modeling, and other computational methods, as applied to biological problems, with emphasis on applications in data-rich areas of molecular biology.

The PSB has been designed to be responsive to the need for critical mass in sub-disciplines within biocomputing. For that reason, it is the only meeting whose sessions are defined dynamically each year in response to specific proposals. PSB sessions are organized by leaders in the emerging areas and targeted to provide a forum for publication and discussion of research in biocomputing’s “hot topics.” In this way, PSB provides an early forum for serious examination of emerging methods and approaches in this rapidly changing field.

Free papers from 1996 – 2006 here

Buku Pengantar Bhs Pemrograman LUA (Hasil PI)

Buku berikut hasil kompilasi penulisan Ilmiah Fitrah, Dian, Pamela, eviyanti, Satyani, mahasiswa Teknik Informatika, Universitas Gunadarma. Meskipun hanya berupa terjemahan user manual LUA, namun saya yakin bermanfaat untuk kita. Buku bisa di download disini (pdf file)

Pendahuluan

Saat ini, banyak bahasa pemrograman yang terfokus pada bagaimana caranya membantu anda menulis program-program dengan ratusan ribu baris. Untuk itu, mereka menawarkan anda paket-paket, namespaces, sistem tipe kompleks, ribuan konstruksi, dan halaman-halaman dokumentasi untuk dipelajari.

Namun tidak pada Lua. Justru, Lua mencoba membantu anda untuk memecahkan masalah dalam ratusan baris, bahkan lebih sedikit. Untuk mencapai tujuan ini, Lua mengandalkan sifat extensibility, seperti banyak bahasa lainnya. Tidak seperti hampir semua bahasa lainnya, bagaimanapun, Lua mudah dikembangkan tidak hanya dengan software khusus yang ditulis dengan Lua, tetapi juga dengan software yang ditulis dengan bahasa lain, seperti C dan C++.

Lua dirancang, sejak awal, untuk terintegrasi dengan perangkat lunak yang ditulis dengan C dan bahasa-bahasa konvensional lain. Dualitas bahasa ini membawa banyak manfaat. Lua merupakan bahasa yang sederhana dan mudah, sebagian karena Lua tidak mencoba untuk melakukan apa yang telah dapat dilakukan bahas C, seperti kinerja yang tipis, operasi low-level, atau penghubung dengan perangkat lunak pihak ketiga. Lua mengandalkan C untuk melakukan tugas tersebut. Apa Yang Lua tawarkan adalah apa yang tidak dapat dilakukan dengan baik pada C : suatu jarak yang baik dari perangkat keras, struktur-struktur dinamis, tanpa redudansi, pengecekan yang mudah dan debugging. Untuk itu, Lua mempunyai lingkungan yang aman, manajemen memori otomatis, dan fasilitas terbaik untuk menangani string dan data jenis lain dengan ukuran yang dinamis.

Lebih dari sekedar menjadi bahasa yang dapat diperluas, Lua juga merupakan bahasa perekat (glue language). Lua mendukung pendekatan berbasis komponen pada perkermbangan software, di mana kita membuat satu aplikasi dengan merekatkan komponen-komponen prioritas tinggi yang ada. Biasanya, komponen-komponen ini ditulis dalam susunan hipunan (compiled), bahasa yang statis, seperti C atau C++; Lua merupakan perekat yang kita gunakan untuk menyusun dan menghubungkan komponen-komponen itu.

Biasanya, komponen-komponen (object) ditunjukkan lebih kongkrit, konsep low-level (seperti widgets dan struktur data) yang bukan subjek pada banyak perubahan selama perkembangan program dan yang mengambil sebagian terbesar waktu CPU dari program akhir. Lua memberi bentuk akhir dari aplikasi, yang mungkin akan mengubah selama daur hidup produk. Bagaimanapun, tidak seperti teknologi glue lainnya. Oleh karena itu kita dapat menggunakan Lua tidak hanya untuk melekatkan komponen, tetapi juga untuk mengadaptasikan dan mengatur bentuk komponen itu, atau bahkan menciptakan seluruh komponen itu.

Tentu saja, Lua bukan satu-satunya bahasa penulisan (scripting language). Terdapat bahasa-bahasa lain yang dapat digunakan dengan tujuan yang hampir sama, seperti Perl, Tcl, Ruby, Forth, and Python. Keunggulan fasilitas-fasilitas berikut menjadikan Lua jauh berbeda dari bahasa-bahasa ini; meski bahasa-bahasa lain berbagi sebagian fasilitas berikut dengan Lua, tidak ada bahasa lain yang menawarkan profile serupa:

· Extensibility: Extensibility Lua sangat menarik perhatian sehingga banyak orang menganggap Lua bukan sebagai suatu bahasa, tetapi sebagai suatu perangkat untuk membangun bahasa-bahasa domain spesifik. Lua telah dirancang untuk diperluas/diaplikasikan, pada kode Lua dan kode eksternal C. Sebagai suatu bukti dari konsep, Lua menerapkan banyak kemampuan dasarnya melalui fungsi-fungsi eksternal. Hal ini sangat mudah untuk menghubungkan Lua dengan C/C++ dan bahasa-bahasa lain, seperti Fortran, Java, Smalltalk, Ada, bahkan dengan bahasa-bahasa penulisan yang lain.

· Simplicity / Sederhana : Lua adalah bahasa yang mudah dan sederhana. Lua mempunyai sedikit konsep (namun tangguh). Kesederhanaan ini membuat Lua mudah dipelajari dan memperbesar suatu implementasi yang sederhana. Distribusinya yang lengkap (source program, manual, biner-biner lebih untuk beberapa platform) sesuai dengan floopy disk.

· Efisiensi: Lua mempunyai implementasi yang efisien. Benchmark-benchmark yang mandiri menunjukkan Lua sebagai bahasa tercepat dalam dunia bahasa penulisan (interpreted).

· Portabilitas: Ketika kita berbicara tentang portabilitas, kita tidak berbicara tentang menjalankan Lua di platform Windows dan Unix. Kita berbicara tentang menjalankan Lua di semua platform yang sudah pernah kita dengar, seperti: NextStep, OS/2, PlayStation II (Sony), Mac OS-9 dan OS X, BeOS, MS-DOS, IBM, EPOC, PalmOS, MCF5206ELITE Evaluation Board, RISC OS, dan tentu saja semua jenis Unix dan Windows. Source program untuk masing-masing platform hampir sama. Lua tidak menggunakan kumpulan kondisi untuk menyesuaikan kodenya kepada mesin-mesin yang berbeda; sebagai gantinya, Lua mengikuti standar ANSI ( ISO) C. Dengan cara itu, biasanya anda tidak perlu menyesuaikan pada suatu lingkungan baru: Jika anda mempunyai satu compiler ANSI C, anda hanya harus meng-kompile Lua, out of box.

Bagian kehandalan Lua terletak pada pustakanya (library). Salah satu dari kekuatan utama Lua yaitu sifat ekstensibilitas pada tipe barunya dan fungsi-fungsinya. Banyak fitur yang berperan dalam kehandalan ini. Pengetikan dinamis mengizinkan tingkat polimorfisme. Manajemen memori otomatis menyederhanakan penghubungan, karena tidak perlu memutuskan siapa yang bertanggung jawab atas alokasi dan dealokasi memori, atau bagaimana caranya menangani overflows. Fungsi-fungsi penugasan yang tinggi (Higher-order) dan fungsi-fungsi tanpa nama mengizinkan suatu prioritas tinggi parametrisasi, pembuatan fungsi-fungsi lebih serbaguna. Lua hadir dengan suatu set kecil pustaka standar. Saat menginstall Lua pada lingkungan dengan kapasitas terbatas, seperti processor, mungkin harus lebih hati-hati untuk memilih pustaka yang dibutuhkan. Lebih dari itu, jika keterbatasan sangan besar, dengan mudah dapat masuk pada pustaka source program dan memilih satu-persatu fungsi-fungsi mana saja yang harus tetap disimpan. Ingat, bagaimanapun, Lua lebih sederhana (bahkan dengan semua standar pustaka) dan dalam kebanyakan sistim anda dapat menggunakan keseluruhan paket tanpa kawatir.

lebih detail silahkan baca bukunya (pdf file)

Computer Supported Collaborative Research (CSCR)

CSCR merupakan bidang baru terkait riset masyarakat HCI. CSCR merupakan kelanjutan dari pendahulunya, yaitu Computer Supported Collaborative Work (CSCW) dan Computer Supported Collaborative Learning (CSCL). Keduanya ini merupakan subyek riset HCI hampir sepuluh tahun yang lalu.

Gambar berikut menampilkan kedudukan dari ketiganya (merupakan bagian dari HCI)

Perbedaan utama antara CSCW dan CSCL yaitu bahwa CSCW dikarakteristikan oleh “kebutuhan akan ruang kerja (workingspace)” sedangkan CSCL membutuhkan ruang kerja dan ruang belajar (learningspace)

Workingspace adalah domain tempat aktivitas-aktivitas berikut berlangsung: communication space, scheduling space, sharing space, dan product space.

Learning space adalah domain yang memuat seluruh aspek workingspace ditambah dengan aktivitas berikut: reflection space, social space, assessment space, tutor space, dan administration space

Perbedaan utama antara CSCR dan CSCL adalah bahwa suatu rekord penuh dari seluruh interaksi antar partisipan merupakan tool penting dan dibutuhkan untuk mengevaluasi kontribusi setiap anggota dalam suatu collaboratiob group yang nanti dapat menentukan “suatu share modal yang adil (a fair capital share) apabila proyek riset berjalan dengan sukses.is successful.

CSCR membutuhkan Workingspace, Learningspace, dan aktivitas-aktivitas berikut: knowledge space, publication space, privacy space, publication space, negotiation space.

(Sumber VH-Hoare)

Introduction to Computational Proteomics

Jacques Colinge, Keiryn L. Bennett

Abbreviations: ESI, electrospray ionization; HMM, hidden Markov model; LC, liquid chromatography; MALDI, matrix assisted laser desorption ionization; MS, mass spectrometry; MS/MS, tandem mass spectrometry; PMF, peptide mass fingerprinting; PTM, posttranslational modifications; TOF, time-of-flight; SPC, shared peak count

Introduction

Proteomics is defined as the protein complement of the genome and involves the complete analysis of all the proteins in a given sample [1,2]. Several technologies are involved, and numerous questions concerning the proteins are addressed. What proteins are contained in a biological sample? At what concentration do the proteins exist? How do protein expression levels alter in different samples? What are the posttranslational modifications (PTMs)? Where in the cell [3] or an organism [4] are the proteins localised? How do the proteins interact with other proteins or molecules [5,6]?

The following discussion concentrates on computational aspects of protein identification. Characterization (identification of protein modifications), quantitation, and sample comparisons are also discussed briefly.

A typical proteomic experiment involves the analysis of complex samples, i.e., containing many proteins at varying concentrations [7]. Most of the currently available technology for identifying proteins from biological samples simply cannot contend with the complexity, and the majority of the low-abundance proteins are not observed. There are, however, a number of methods to separate the proteins contained in the original sample to obtain a simpler sample set that is amenable to in-depth analyses. Typical technologies are electrophoretic gels [8] and liquid chromatography [9] (LC) (see Figure 1A).

Figure 1. Steps in Sample Analysis by Proteomics

(A) Sample complexity reduction via an LC column. This is applicable to both proteins and peptides. It is possible to collect fractions at fixed or variable time intervals to obtain a series of less complex samples; however, direct MS analysis is also an option. The figure illustrates how peptides/proteins 1–11 are fractionated.

(B) Major steps in “bottom-up” proteomics and combinations thereof. Optional steps and essential steps are in rounded and bold rectangles, respectively. Green represents shotgun peptide sequencing entire sample digestion followed by multidimensional LC separation of peptides. Blue represents the classical gel approach, with or without (dashed arrows) peptide LC. Red combines protein and peptide LC.

(C) Data-dependent MS/MS analysis. Here, ESI of a liquid sample and alternation of the instrument between MS and MS/MS modes is illustrated. The data generated is a sequence of peptide experimental m/z associated with the corresponding fragments m/z. The complete analysis is named an LC-MS run.

A dominant and well-practiced technique in proteomics is referred to as the “bottom-up” approach. Proteins are digested into peptides (smaller components of the protein) by a proteolytic enzyme, e.g., trypsin. Analysis of the peptides is achieved by mass spectrometry (MS), and, from the data generated, the peptides (and subsequently the proteins) can be identified. The resultant mixture of peptides obtained from the digestion of several proteins is often highly complex, and a degree of separation can be achieved by peptide LC. Possible combinations of separation techniques are illustrated in Figure 1B.

Mass spectrometers comprise three main components: an ion-source, a fragmentation cell, and a mass analyzer. Each component is essentially independent from the others, and as such it is possible to combine the different technological aspects to produce different types of mass spectrometers. To measure its molecular mass, a molecule must be ionised. This occurs in the ion source of the mass spectrometer. The source can be based either on electrospray ionization [10] (ESI), which is therefore appropriate for liquid samples; or on matrix assisted laser desorption ionization [11] (MALDI), which is appropriate for samples that have been mixed with a matrix and crystallized on a metallic plate. The most common types of mass analyzers used in proteomic laboratories are (i) ion trap (IT), where the radio frequency of the trap is varied and the ejected ions are detected; and (ii) time-of-flight (TOF) analyzers, where the time required for an ion to “fly” through an electric field–free region of the instrument is recorded and correlated to the mass of the ion. Most current instruments include a fragmentation cell that uses an inert gas to break the peptides by collision-induced dissociation (CID). A fragmentation cell, however, is not always present (see next section), or fragmentation can occur “spontaneously” (in-source and post-source decay). All mass spectrometers do not measure mass directly, but rather the mass-to-charge ratio. Hence the measurements obtained are dependent on the charge state(s) of the molecule.

here the paper from PLOS