The feof() function in PHP is an inherent function that checks a file pointer for the end-of-file. It determines whether or not the “end-of-file” has been reached. If the size of the content of a file is not known ahead of time, the feof() method is used to loop over it.

Why feof () used in Reading file ?

If the end-of-file has been reached or an error has occurred, the feof() method returns True. Otherwise, False is returned.

Syntax:

feof( $file )

Parameters:

In PHP, the feof() method takes only one parameter, $file. The file to be examined for end-of-file is specified by this argument.

Return Value:

If the end of the file has been reached or an error has occurred, it returns TRUE. Otherwise, False is returned.

Errors And Exception:

• If the supplied file reference is invalid, it enters an infinite loop since end-of-file does not return True.
• If a connection opened by fsockopen() is not terminated by the server, the feof() function hangs.

Let’s take one Example:-

Below examples will explain the feof() function:

Example 1:- In the below program the file named “test.txt” contains only a single line of text which is “This file consists of only a single line.”.

Output:

Example 2:- In the below program the file named “test-test.txt” contains the following text.

This is the first line.
This is the second line.
This is the third line.

Output:

The post Tutorial for feof () in Reading file appeared first on scmGalaxy.

A loop is an Iterative Control Structure that requires the same number of codes to be executed several times until a specific condition is met. When writing code, you may want a specific block of code to run a certain number of times. As a result, rather than applying nearly similar code lines to a script, we can employ loops.

What are the Different types of Loops?

Loops are used repeatedly to run the same piece of code as long as a given condition is met. A loop’s basic premise is to simplify recurring procedures in a programmer in order to save time and effort. PHP supports four different loop styles.

• while – Loops through a code block as long as the given condition is true.
• do...while – The code block running once and then is tested. State. If the condition is true, the declaration shall be repeated until the condition stated is true.
• for – Loops via a code block before a given number is reached in the counter.
• foreach – Loops for each unit of an array across a block of code.

Why to Use Loops?

When trying to recreate code, it might be tedious to retype or copy and paste the same code over and over again. Worse, unintentional mistakes might lead to programme malfunctions.

That’s quite a few keystrokes! What if you decide later that you want to start each statement with “The count is currently: ”? You’d have to copy it and paste it into every single line.

Fortunately, loops are a function in most programming languages that allows you to automatically repeat code before such requirements are met. Iteration is a phrase used to describe the repetition of code, and it refers to each time the code is executed. Loops will reduce the number of lines of code you write while still allowing you to update it later.

PHP is no exception, as it offers a variety of ways to repeat the execution of a code block.

This Article has cover the following PHP loop types:

• while
• do … while
• for
• foreach

There are conditions in each of these loops that prevent the loop from executing. If these requirements are not met, an endless loop will follow, and the software will never be able to quit executing the code block.

How to use loops in PHP?

In order to write effective code, any programmer needs have a thorough understanding of loops and how to use them effectively in programming.

When writing code, we must always repeat a same set of functions. Performing them one at a time would result in a higher number of lines of code and a longer duration. As a result, the software gets more difficult to understand. As a result, instead of using loops to run the code, we can use them!

The post Tutorials for PHP Loops appeared first on scmGalaxy.

The information or variables included within the function’s parentheses are referred to as parameters. These are used to keep track of values that can be used during runtime. The comma(,) operator allows the user to input as many arguments as he wants. These options are used to accept inputs during runtime. When transferring numbers, such as during a function call, arguments are used. A parameter is a container for parameters that are given to a function. A value supplied to a function is referred to as an argument. In layman’s terms, both parameter and statement have the same meaning. It’s crucial to keep in mind that each parameter must be accompanied with an argument.

Syntex:-

function function_name($first_parameter, $second_parameter) {
    executable code;
}

Example:-

Setting Default Values for Function parameter:-

In PHP, we may define default arguments for function parameters. If no argument is supplied for a parameter with a default value, PHP will call the function with the parameter’s default specified value.

The default value for the parameter $num in the previous example is 12; if no value is supplied for this parameter in a function call, the default value is used. It’s also required because the option $str has no default value.

Functions with return values:-

Functions can also return values to the portion of the program where they were called. The value is returned to the program section from where it was named using the return keyword. It is possible to return any type of value, including arrays and objects. The return statement also marks the conclusion of the function, stops it from running, and returns the value.

Parameter passing to Functions:-

In PHP, there are two ways to pass an argument to a function.

Pass by Value:– Moving by value changes the value of an argument within a function, while the original value outside the function stays unaffected. This means that a statement that is a duplicate of the original value is transmitted.

Pass by Reference:– As statements are passed via proxy, the original value is transmitted. As a result, the starting value has changed. Using the ampersand symbol in pass by reference, we just transmit the value’s address, where it is kept (&).

Example:-

The post Tutorials for PHP Function with Parameters or Arguments appeared first on scmGalaxy.

A function is a segment of code in a program that is written to do a certain task. We should compare functions to workers in a real-world workplace to have a better grasp of how they work. Assume the management delegated the duty of determining the annual budget to one of his employees. So, what will be the outcome of this procedure? The employee would ask his supervisor for data, perform estimations, calculate the budget, and report the results to his superior. Functions work in a similar fashion. They accept data as an argument, process it using a set of statements or operations, and then return the output.

How many Types of Functions in PHP?

There are Two Types of Functions :-

User Defined Functions:-These capabilities are used by developers and programmers when they need to execute their own logic. This functions are specified with the keyword function, and when a function call is made, a sequence of statements will be written within the function to execute it. Simply type functionname() in the address bar, and the function will be run.

Built-in functions:- These routines offer us with already-built-in library functionality. The PHP installation kit includes several capabilities, making the language more efficient and helpful. To use the function’s attributes, all we have to do is call it when we want the desired outcome. PHP makes use of date, numeric, string, and other built-in functions.

• String Functions: These PHP features include built-in support for working with strings. Some of the string methods in PHP include strpos(), strncmp(), strrev(), and strlen() ,
• Date Function: The format is a human-readable UNIX date and time format, and these functions are PHP standard components.
• Numeric Functions: These functions have their own preset logic for numeric operations that PHP provides. As a result, it will either return a Boolean or a numeric value. Among them are is number(), number format(), round(), and other numeric procedures.

Why we should Use Functions in PHP?

Reusability:- This programming language has a feature that reduces the amount of lines of code that must be written many times. This would save time and effort for the developer or coder. We can put a piece of code in a feature and call it whenever and wherever it’s needed if it has to be used in many locations. This may be done by calling the functions from other programmes or from inside the same package.

Easier Error Detection:- Because the code is written as functions rather than single blocks, any problems may be immediately and readily recognized and rectified.

Easily Maintained:- Because functions are used throughout the program, we may quickly modify any function or line of code in the function, and the change will be reflected. As a result, it is simple to maintain everywhere.

How to create functions in PHP?

A function is to find a collection of statements in a programmer repeatedly. When a function in a program is invoked, it is simply implemented. There are a few things to keep in mind while creating a user-identified feature.

• Any word ending in an opened and closed parenthesis is a feature.
• The function keyword is commonly used to start a name of the function.
• Type your name followed by a parenthesis to launch a command.
• The initial letter in a function word cannot be a number. It might start with a letter or an emphasis.
• The name of a feature is important.

Example:-

The post Tutorials for PHP Functions appeared first on scmGalaxy.

Their sizes, as well as the names of the variables, might change. In most programming languages (such as C++ and Java), you may use a number of data types for variables. However, because PHP does not specify type explicitly, the variable type must be determined by the form or type of data to which it is applied.

What are the Data Types used in PHP?

There are many data types for various purposes, such as null, binary, integer, float, text, object, property, and an array. We employ eight different types of data in PHP to create our variables. Below is a brief explanation of the various categories.

Integers − There are whole numbers, including 4195, without a decimal point.

Doubles − Floating points are numbers such as 3.14159 or 49.1

Booleans − Have either true or false only two possible values.

NULL − It has only one value: NULL, is a special kind.

Strings − There are character strings, such as ‘PHP supports string operations.’

Arrays − Collections of other values are called and indexed.

Objects − There are instances of programming classes that can package other class-specific values and functions.

Resources − Special variables provide access to external PHP tools (such as database connections).

The post Tutorials for PHP Data type appeared first on scmGalaxy.

In any programming language, a variable is a computer memory name that represents knowledge. One of the numerous computer program components is the variables. For declare a variable in php, the $ sign with its signature, like $myVariable, can be used.

How to declare PHP variable?

• All variables in PHP start with a $(doller) sign followed by the name of the variable.
• A valid Variable name starts with a letter (A-Z, a-z) or underscore(_), followed by any number of letters, numbers, or underscores.
• If a variable name is more than one word, it can be separated with underscore(for example $employee_code instead of $employeecode).
• ‘$’ is a special variable that can not be assigned.

What are the Types of Variable?

Local Variables:- A local variable is one that only exists inside a certain scope. They only exist in the function in which they were created. They’re frequently referred to as automatic variables since they’re produced automatically when the function starts running and disappear immediately when it’s completed. The term auto can be used to create these variables explicitly, but it isn’t required because auto is the default.

Global Variables:- A global variable is one that is defined outside of all functions and is accessible to all of them. These variables are unaffected by scopes and are always accessible, implying that a global variable persists until the program is terminated. It’s possible to make a global variable in one file and use it in another. The variable must be defined in both files to do this, but the term extern must come before the “second” declaration.

Static Variables:- A global or local variable can be a static variable. Both are generated by using the term static before the variable definition. A local static variable is one that can keep its value from one function call to the next and will persist until the program is finished. When creating a local static variable, it should be given an initial value. If it isn’t, the value will be set to 0 by default. A global static variable may only be accessed within the file in which it was created. File scope is a term used to describe a variable’s scope.

Variable Initialization?

PHP can store all type of data in variables. Before using a variable in PHP, assign a value to it so PHP will create that variable and store data in it. That means we have to assign data to a variable before attempting to read a variable’s value.

Example:-

$roll = 256;
$price = 25.50;
$name = “Geeky Shows”;
Note - If a variable is created without a value, it is automatically assigned a value of NULL.

The post Tutorials for PHP Variables appeared first on scmGalaxy.

The server executes the PHP script, which will send the HTML output to the browser. Normally HTML and PHP tags can be present. A popular open source general programming language, PHP or Hypertext Preprocessor may be built into an HTML. The .php extension is used to store PHP files. In PHP tags, PHP scripts and standard HTML may be written in any page.

For beginners or pros alike, PHP is a pleasant language to use. We start working with PHP in this PHP Tutorial Series on the first floor. Even more experienced developers who need refreshment are very great to start from the start. Frequently you will realize that sophisticated difficulties are often a fairly fundamental mistake. That’s what makes the fundamentals so vital. They are the foundation for building on your whole understanding of programming. So let’s start getting our hands dirty with PHP today we look at what PHP is, and the history of this some times contentious language.

Examples:-

The post Basic Structure of PHP appeared first on scmGalaxy.

The PHP programmer communicates with the website server, which transmits web pages to the rest of the globe. You are instructing the web server in the URL to send an HTML file if you input a URL in your web browser’s address bar. The requested file is sent by the web server. Your browser reads the HTML file and displays the site. You also request a file from the web server when you press a source on a webpage. In addition, when you click a web page button that submits a form, a file is processed by the web server. The method is precisely the same when PHP is mounted. You are submitting a file and, because of PHP, the web server that runs PHP answers with HTML. Through these steps you can stand:-

Step-1:- Client send a page request to the web server.

Step 2 – Web server forwards that request to the PHP interpreter.

Step 3 – Now PHP interpreter will take the Date from Database and response it back to the Web server.

Step 4 – At last Web server response to the client who has asked for the page request.

The post How PHP works? appeared first on scmGalaxy.

PHP is an open source programming and server scripting language that is especially well suited for creating static or dynamic web pages, as well as Web applications, and may be included in HTML codes. It’s used to develop full e-commerce websites, as well as handle complicated content, databases, and session logging. Although PHP is now commonly known as a hypertext preprocessor, it was originally known as Personal Home Page. It was created in 1994 by Rasmus Lerdorf, a programmer. PHP is a reasonably straightforward language to learn, but you must first have a solid understanding of HTML. PHP works with a variety of databases, including MySQL, PostgreSQL, Oracle, Sybase, Informix, and Microsoft SQL Server, and may communicate with other services using LDAP, POP3, HTTP, IMAP, and COM protocols. PHP runs on a variety of operating systems, including Windows, Linux, Unix, and Mac OS X, among others.

What are the features of PHP?

The beauty of PHP is that it is extremely simple for a beginner to learn while still providing a variety of advanced capabilities for a seasoned developer. Don’t be scared off by PHP’s extensive list of capabilities. In a few of hours, you should be able to start developing simple programmes.

• On a computer, PHP performs system activities like as creating, opening, reading, writing, and closing files.
• PHP can handle formats, which means it can get data from databases, save it to a file, email it to the user, and return it to them.
• You can edit, delete, and add entries to your database using PHP.
• PHP’s main focus on Server-side scripting. If you want to practice as an independent at home, that’s the way forward.
• Command line scripting is suitable for scripts in scheduling tasks. For simple text editing, it is also handy.
• PHP helps us communication on all servers, such as MySQL, back-end/database.
• To get the current date you will use PHP and then build a monthly calendar.
• The HTML code generation in web browsers is often used by PHP.
• PHP may be used to rotate the banner advertising on your website.
• You may use PHP to limit the access of a user to one web page.
• You may create a login page with PHP for your user.
• Set up a database with a web browser.

Why we use PHP Language?

You’ve heard of several other programming languages, and perhaps are interested about why we select PHP as our web programming poison. PHP is well documented online and has a robust function structure. The language is therefore reasonably easy to learn and has a big online community. There are a host of PHP techniques and difficulties forums and manuals, so you should find no help if you want them. Here’s a fundamental point.

• It works on several systems, such as Windows, Linux and Unix.
• It works for several databases such as MySQL, PostgreSQL and Oracle.
• PHP is a free open source programming language for anybody.
• The learning curve is relatively quick in contrast to other languages like as JSP, ASP, and others.
• The language can be easily collected and used on the server side. It works nicely.
• This is perfect for creating the web since it can be included into the HTML code directly.
• It is commonly used in combination with Apache on many operating systems (the application server). It is also Microsoft IIS compatible on Windows.
• PHP may also be used for the production of interactive websites.
• PHP also has the benefit of a server-side scripting language, which means that you just have to install it on your server. Client computers requiring server services are unnecessary for PHP. It is sufficient to use a web browser.

The post What is PHP? appeared first on scmGalaxy.

Azure DevOps includes the following services:

• Azure Boards

It is a powerful agile tool for managing Kanban board, reporting, and product backlog. It also helps you to plan, track, and discuss work across the team.

It has components like work items, backlogs, Boards, queries, sprints details.

• Azure Repos

Azure Repos service provides you unlimited cloud-hosted private Git repository for your project. This is a type of standard Git service and works use as distributed source controls. Azure Repos supports all Git clients and all IDEs.

• Azure Pipelines

It is a cloud-hosted pipelines that helps you in for fast CI/CD that works with any language, platform, and cloud. It helps you with continuously changes Release by connecting to any source control like GitHub, this service can release changes continuously to any cloud. Azure Pipelines has components like build, release, library, task groups, and deployment groups.

• Azure Test Plans

Azure Test Plans provides manual and exploratory testing tools. It also help you to do automated and manual testing.  XML files can be used for load testing as well.

• Azure Artifacts

Azure Artifact service manages the dependencies used in source code. It can host and share package (like NPM, Nuget, and Maven) feeds from public and private sources. These artifacts simplify job building process.

Benefits of Azure DevOps

Azure DevOps allows their users to develop, deploy, and monitor code without opening multiple interfaces and you can also manage all of this from one view and bring ease to the customers.

Some of the main benefits are

• Timely Access to New Features

Every three weeks, DevOps users receive access to new features. No need to scramble around and wonder what’s new. These are not to be confused with upgrades, and speaking.

• No Upgrades to Worry About

Users need not worry about upgrading or patching up the toolchain because the Azure DevOps is a SaaS product. Companies that run on a CI/CD model no longer need to slow things down for the sake of upgrading.

• Reliability

Azure DevOps is backed by 24 x7 support and a 99.9% SLA.

• Flexibility

If your DevOps team doesn’t want or need the full suite of services, they can acquire them independently.

• Platform-agnostic

DevOps is designed to run on any platform like Linux, macOS, and Windows or language for example Android, C/C++, Node.js, Python, and Java, PHP, Ruby, .Net, and iOS apps.

• Cloud-agnostic

Azure DevOps works with AWS and GCP.

Why we use Azure DevOps?

There has been a lot of buzz lately about Azure DevOps and you may be wondering– why we use Azure DevOps?

Here are some of the reasons to consider Azure DevOps:

Azure DevOps is a feature-rich platform. The flexibility of supported languages, platforms and cloud vendors make it a viable option for a huge range of organisations.  However, if you’re currently running an on-premises Team Foundation Server moving to Azure DevOps would be a natural upgrade for you.

Azure DevOps is not focussed at organisations that are end-to-end Microsoft or Windows. Azure DevOps provides a platform that is:

• Flexible

You don’t have to go ‘all in’ on Azure DevOps. It is possible to adopt each of the services independently and integrate them with your existing tool chain, most popular tools are supported.

• Platform agnostic

Designed to work with any platform (Linux, MacOS and Windows) or language (including Node.js, Python, Java, PHP, Ruby, and C/C++, .NET, Android and iOS apps) Azure DevOps is not just aimed at organizations building and shipping.

• Cloud Agnostic

Continuous delivery is supported to AWS and GCP as well as to Azure.

How long it take to Lean Azure DevOps?

If you have prior experience in software, programming, scripting, Linux, and Automation then you can learn DevOps basics such as CI/CD pipeline and its tools in one month.

If you have prior experience of software, programming, and scripting but not familiar with Linux, and Automation then you have to learn Linux and Automation first before learning DevOps basics such as CI/CD pipeline and its tools in 2-3 months.

 If you have prior experience of computer and software background but no experience in programming, scripting, Linux, and Automation then programming and scripting take two months, one month for OS and automation fundamentals, and one month for learning DevOps basics such as CI/CD pipeline and its tools. Overall, 4-5 months.

Roles and Responsibilities

DevOps Engineer works with developers and the IT team to oversee the code releases. Many-times developers who get interested in deployment and network operations or sysadmins who have a passion for scripting and coding and move into the development side where they can improve the planning of test and deployment.

Roles of Azure DevOps Engineer

• Implementing Continuous Feedback.
• Implementing Application Infrastructure.
• Implementing DevOps Development Processes.
• Implementing Dependency Management.
• Implementing Continuous Integration.
• Implementing Continuous Delivery.

Career opportunity as an Azure DevOps Engineer?

Azure DevOps Engineer is someone who has an understanding of the Software Development Lifecycle and if familiar with various automation tools for developing digital pipelines (CI/ CD pipelines).

Azure DevOps Engineers are responsible for defining and implementing a robust, scalable, pragmatic and realistic cloud solution that works for our clients. Design and implement cloud solutions which are secure, scalable, resilient, monitored, auditable and cost optimized.

So what are the options in front of you when you complete your Certification as an Azure DevOps Engineer?

Here are a few job roles that you can fill:

• Cloud Engineer
• DevOps
• Cloud Specialist
• High Availability
• MEAN
• Shell Scripting
• Big Data
• Windows Admiration

Salary of an Azure DevOps Engineer

More than 500 top Fortune companies as well as start-ups or small businesses that need an Azure DevOps Engineer who is certified and are ready to offer a lucrative Azure DevOps Engineer. So, don’t worry about the job prospect or salary aspect when it comes to being a certified Azure DevOps Engineer, just focus on upscaling your real-time expertise when you wish to be a part of any of these renowned organizations and get to work with your dream company with the salary you wished for. 

As an Azure DevOps engineer, the national average salary is $103,314.

• The DevOps engineer based on 3 years of experience can expect $7,927 per annum.
• The salary for the aforementioned experience ranges from $3,329 – $18,886.
• Also, the Azure DevOps engineer salary is also dependent on experience such as Entry level, Intermediate, Senior ranging from $79,000 – $134,000.
• Furthermore, Azure DevOps engineer salary also depends on the certification obtained through training platforms such as JanBask Training.

Now let us have a look at a range of salaries across the globe.

• The Azure DevOps Engineer Salary in the United Kingdom on average is £82,472 per year or £29.18 per hour. 
• The Azure DevOps Engineer Salary in the US on average is $136,500 per year or $70 per hour. 
• The Azure DevOps Engineer Salary in India on average is ₹ 2,100,000 per year or ₹ 1,077 per hour.
• The Azure DevOps Engineer Salary in Australia starts from an average of $130,000 per year or $66.67 per hour. 
• The Azure DevOps Engineer Salary in Canada on average is $120,938 per year or $62.02 per hour.

Conclusion

In this Article, we all discussed on point of a career in Azure DevOps. We provided you the enough information about the salaries what you can expect to earn in different job roles with skills We also discussed the options that you can choose as a skilled DevOps professional depending on your interests. If you are curious to learn about Azure DevOps, and make a good career with this skill then I would suggest you please check out DevOpsschool.com for more information.

The post Why should I used Azure DevOps? appeared first on scmGalaxy.

It’s not shocking that a lot of organizations struggle when it comes to DevOps execution. DevOps is a new conception which IT organizations use to enhance collaboration between two functions into one. In today’s cutthroat business environment, DevOps comes as an important resolution that helps organizations meet ever-growing business demands.

The meaning of DevOps is different for different peoples. Some says it’s a “collaboration of operations and developers” or it’s using automation or it is a toolchain approach or culture or a job title or it’s just a Dev. and Ops. or variety of related things. But if we look onto it, it’s not just a set of tools or not just a culture or job title. We can say It is a way of doing work where people of both operations and developer skill sets work together on projects to create quality products without wasting resources and infrastructure in a short span of time by using best practices of tools.

There are many organizations in the world who are adopting DevOps to enhance their employee Performances and revenues and profitability of their business. There are many studies done till date where it is clearly shown that where companies implement the DevOps approach get more done, plain & simple. The greatest change in approach in a DevOps environment is that there is a single group made out of cross functional members including operations architects, business expert, DBA’s, QA, developers and so forth. There are many advantages of collaboration among these different roles delivers.

If we look on to benefits there are:-

1. Continuous software delivery

2. Less complex problems to fix

3. Faster resolution of problems

4. Faster delivery of features

5. More stable operating environments

6. More time available to add value (rather than fix/maintain)

To accomplish this, Dev and Ops must break the silos and work together with each other, share liability for keeping up the framework that runs the product, and set up the product to keep running on the framework with continuous quality input and delivery automation.

In this process there are so many tools and practices used to achieve the results. Source Code Repository, Build Server, Configuration Management, Virtual Infrastructure, Test Automation and Pipeline Orchestration any many more in the process.

DevOps is certainly a group activity, however it’s still vital to clearly define once roles and liabilities for accomplishment inside the group. Means to say it is really important for organizations to make sure dev and ops teams are collaborating and sharing responsibilities throughout the software delivery lifecycle from planning all the way to managing the production environment.

Now the real problem is that there are various challenges an organization and their employee’s face when they trying to execute DevOps skills because they do not able to overcome the Developers and Operations mentality and unable to do continuous balance and change of work process, they lack of understanding the security and access management, unable to do continuous monitoring, Toochain cashes of Developers and operations and various others problems they face when they try to implement it on their projects. To overcome these challenges organization’s must provide their employees DevOps skills from industry experts. Now to make your job easy I did some research on it and found one portal “DevOps Consulting” where you can get best industry trainers and consultants for corporate and individual training.

The post Why organization should enhance DevOps skills of their employee? appeared first on scmGalaxy.

Cheap Local Branching

Git is the new standard

The post Why Git is Better than X | Git or X appeared first on scmGalaxy.

What is Code Coverage
Code Coverage is an important measurement in Software Quality Engineering. While Software testing ensures correctness of the applications, a metric is required to track the What is Code Coverage Code Coverage is an important measurement in Software Quality Engineering. While Software testing ensures correctness of the applications, a metric is required to track the completeness and effectiveness of the testing undertaken. Code Coverage helps achieve reliable quality through identifying untested areas of the application.

Why Code Coverage
Software testing is a challenging function. The testers need to ensure complete functional and non-functional correctness of the product. Considering the complex workflows and use cases of modern day applications, the number of unique cases that the software can be used often run into millions, which is not feasible to be covered under testing exercise. The testers thus need to
– While Planning Tests
o Ensure covering all workflows in terms of decision trees in the code
o Ensure covering all data values – by identifying patterns rather covering millions of values
– While testing
o Ensuring the testing is completely exercising the whole application with planned and exploratory tests.

At the end of testing, the decision to stop testing and release the product still remains subjective, based on the presence or absence of bugs, inflow of new bugs, success rate of each test cycle, confidence rating of the testers or users, etc. Whereas the definitive metric of quantifying how much of the application was really tested, is missed.

Code Coverage is measured as quantification of application code exercised by the testing activities. Code Coverage can be measured at various levels – in terms of programming language constructs – Packages, Classes, Methods, Branches or in terms of physical artifacts – Folders, Files and Lines. For Eg. A Line Coverage metric of 67% means the testing exercised 67% of all executable statements of the application. A Code Coverage metric usually is accompanied by Code Coverage Analysis Report – which helps identify the un-tested part of the application code, thereby giving the testers early inputs for complete testing.

Benefits of Code Coverage

• Objective Indicator of Test Coverage of application code
• Pointers to uncovered Packages / Classes / Methods / Branches
• Pointers to uncovered Folders / Files / Lines
• Drill down to untested part of source code and devise new tests
• Early Indicator for Testing Quality and Fixing it by adding new tests.
• Remove redundancy in testing
• Increased Confidence for Releases

Test Your Test

Typical Emotional Storyboard

• Write Some code! Happy!
• Does it work? Sad!
• Write some test! Happy!
• Do they really test the code? Sad!
• Measure the Code Coverage! Happy!

Coverage Measurement

1. Shows Which line of code are executed
2. How much of your code is covered by your tests?
3. Your tests test your product
4. Coverage testing tests your tests

Goal

• 100%
• Coverage Ideal
• Not Always possible
• Can be expensive to achieve
• Design for testability

Good: Write more tests
Only way to truly increase code coverage

Bad
Excluding Code to boost Coverage

Types of Coverage

1. Statement Coverage
2. Branch Coverage
3. Path Coverage
4. Loop Path Coverage
5. Data – driven Code
6. Complex Conditionals
7. Hidden Branches

How; – Coverage Tools

1. Clover
2. Cobertura
3. Emma

The post What is Code Coverage and Why Code Coverage? appeared first on scmGalaxy.

This article is a summary of a seminar I had on the topic. If it seems like it’s a continuation of an existing discussion that’s because, to some extent, it is. If you haven’t been discussing exchanging your app server, this article probably isn’t very interesting to you.

By putting the application server inside my application instead of the other way around, I was able to leap tall buildings in a single bound.

The embedded application server

This is how I deploy my sample application to a new test environment (or to production):

1. mvn install
2. scp -server/target/-1.0.onejar.jar appuser@appserver:/home/appuser/test-env1/
3. ssh appuser@appserver “cd /home/appuser/test-env1/ && java -jar -1.0.onejar.jar&”

This require no prior installed software on the appserver (with the exception of the JVM). It requires no prior configuration. Rolling back is a matter of replacing one jar-file with another. Clustering is a matter of deploying the same application several times.

In order to make this work in a real environment, there are a many details you as a developer need to take care of. As a matter of fact, you will have to take responsibility for your operational environment. The good news is that creating a good operational environment is not more time-consuming than trying to cope with the feed and care of a big-a Application Server.

In this scheme every application comes with its own application server in the form of jetty’s jar-files embedded in the deployed jar-file.

The advantages

Why would you want to do something like this?

• Independent application: If you’ve ever been told that you can’t use Java 1.5 because that would require an upgrade of the application server. And if we upgrade the application server, that could affect someone else adversely. So we need to start a huge undertaking to find out who could possibly be affected.
• Developer managed libraries: Similar problems can occur with libraries. Especially those that come with the application server. For example: Oracle OC4J helpfully places a preview version of JPA 1.0 first in your classpath. If you want to use Hibernate with JPA 1.0-FINAL, it will mostly work. Until you try to use a annotation that was changed after the preview version (@Discriminator, for example). The general rule is: If an API comes with your app server, you’re better served by staying away from it. A rather bizarre state of affairs.
• Deployment, configuration and upgrades: Each version of the application, including all its dependencies is packaged into a single jar-file that can be deployed on several application server, or several times on the same application server (with different ports). The configuration is read from a properties-file in the current working directory. On the minus side, there’s no fancy web UI where you can step through a wizard to deploy the application or change the configuration. On the plus side, there is no fancy web UI …. If you’ve used one such web UI, you know what I mean.
• Continuous deployment: As your maven-repository will contain stand alone applications, creating a continuous deployment scheme is very easy. In my previous environment, a cron job running wget periodically was all that was needed to connect the dots. Having each server environment PULL the latest version gives a bit more flexibility if you want many test environments. (However, if you’re doing automated PUSH deployment, it’s probably just as practical for you).
• Same code in test and production: The fact that you can start Jetty inside a plain old JUnit test means that it is ideal for taking your automated tests one step further. However, if you test with Jetty and deploy on a different Application Server, the difference will occasionally trip you. It’s not a big deal. You have to test in the server environment anyway. But why not eliminate the extra source of pain if you can?
• Licenses: Sure, you can afford to pay a few million $ for an application server. You probably don’t have any better use for that money, anyway, right? However, if you have to pay licenses for each test-server in addition, it will probably mean that you will test less. We don’t want that.
• Operations: In my experience, operations people don’t like to mess around with the internals of an Application Server. An executable jar file plus a script that can be run with [start|status|stop] may be a much better match.

The missing bits

Taking control of the application server takes away a lot of complex technology. This simplifies and makes a lot of stuff cheaper. It also puts you back in control of the environment. However, it forces you to think about some things that might’ve been solved for you before:

• Monitoring: The first step of monitoring is simple: Just make sure you write to a log file that is being monitored by your operations department. The second step requires some work: Create a servlet (or a Jetty Handler) that a monitoring tool can ping to check that everything is okay. Taking control of this means that you can improve it: Check if your data sources can connect, if your file share is visible, if that service answers. Maybe add application-calibrated load reporting. Beyond that, Jetty has good JMX support, but I’ve never needed it myself.
• Load balancing: My setup supports no load balancing or failover out of the box. However, this is normally something that the web server or routers in front of the application server anyway. You might want to look into Jetty’s options for session affinity, if you need that.
• Security: Jetty supports JAAS, of course. Also: In all the environments I’ve been working with (CA SiteMinder, Sun OpenSSO, Oracle SSO), the SSO server sends the user name of the currently logged in user as an HTTP header. You can get far by just using that.
• Consistency: If you deploy more than one application as an embedded application server, the file structure used by an application (if any) should be standardized. As should the commands to start and stop the application. And the location of logs. Beyond that, reuse what you like, recreate what you don’t.

Taking control of your destiny

Using an embedded application server means using the application server as a library instead of a framework. It means taking control of your “main” method. There’s a surprisingly small number of things you need to work out yourself. In exchange, you get the control to do many things that are impossible with a big-A Application Server.

Reference: http://www.javaworld.com/community/

The post Why and how to use Jetty in mission-critical production appeared first on scmGalaxy.

Why Worry About Versioning?

Having a good version scheme for your software is important for several reasons. The following are the top five things a version scheme allows you to do (in random order):

Track your product binaries to the original source files.

Re-create a past build by having meaningful labels in your source tree.

Avoid “DLL hell” —multiple versions of the same file (library in this case) on a machine.

Help your setup program handle upgrades and service packs.

Provide your product support and Q/A teams with an easy way to identify the bits they are working with.

So, how do you keep track of files in a product and link them back to the owner? How can you tell that you are testing or using the latest version of a released file? What about the rest of the reasons in the list? This chapter describes my recommendations for the most effective and easiest way to set up and apply versioning to your software. Many different schemes are available, and you should feel free to create your own versioning method.

Ultimately, like most of the other topics in this book, the responsibility to apply versioning to the files in a build tends to fall into the hands of the build team. That might be because it is usually the build team that has to deal with the headaches that come from having a poor versioning scheme. Therefore, it is in their best interest to publish, promote, and enforce a good versioning scheme. If the build team does not own this, then someone who does not understand the full implications of versioning will make the rules. Needless to say, this would not be desirable for anybody involved with the product.

File Versioning

Every file in a product should have a version number; a four-part number separated by periods such as the one that follows seems to be the established best practice. There are many variations of what each part represents. I will explain what I think is the best way of defining these parts.

…

Major version— The component owner usually assigns this number. It should be the internal version of the product. It rarely changes during the development cycle of a product release.

Minor version— The component owner usually assigns this number. It is normally used when an incremental release of the product is planned instead of a full feature upgrade. It rarely changes during the development cycle of a product release.

Build number— The build team usually assigns this number based on the build that the file was generated with. It changes with every build of the code.

Revision— The build team usually assigns this number. It can have several meanings: bug number, build number of an older file being replaced, or service pack number. It rarely changes. This number is used mostly when servicing the file for an external release.

Build Number

Each build that is released out of the Central Build Lab should have a unique version stamp (also known as the build number). This number should be incremented just before a build is started. Don’t use a date for a build number or mix dates into a version number simply because there are so many date formats out there that it can be difficult to standardize on one. Also, if you have more than one build on a given date, the naming can get tricky. Stick with an n=n+1 build number. For example, if you release build 100 in the morning and rebuild and release your code in the afternoon, the afternoon build should be build 101. If you were to use a date for the build number, say 010105, what would your afternoon build number be? 010105.1? This can get rather confusing.

It is also a good idea to touch all the files just prior to releasing the build so that you get a current date/time stamp on the files. By “touching” the files, I simply mean using a tool (touch.exe) to modify the date/time stamp on a file. There are several free tools available for you to download, or you can write one yourself. Touching the files helps in the tracking process of the files and keeps all of the dates and times consistent in a build release. It also eliminates the need to include the current date in a build number. You already have the date by just looking at the file properties.

In addition, try to avoid tools that inject version numbers into binaries (as a post-build step). Although the tools might seem reliable, they introduce an instability factor into your released binaries by hacking hexadecimal code. Most Q/A teams become distressed if this happens to the binaries they are testing—and justifiably so. The build number should be built into the binary or document files.

Source Code Control Trees

All the source code control (SCC) software that I have seen has some kind of labeling function to track either checked-in binaries or source code. (Remember that I am not for checking in binaries, but I mention this for the groups or teams that do. This type of versioning (or more appropriately named labeling) is typically used to track a group of sources that correspond to a product release. Most of the time, they combine labeling of the sources with the branching of the source code lines.

Should There Be Other Fields in the File Version Number?

I am of the opinion that no, there shouldn’t be other fields in the file version number. Let’s look at some other fields that might seem like they should be included but really don’t need to be:

• Virtual Build Lab (VBL) or offsite development group number— You can use this number to track a check-in back to a specific site or lab that the code was worked on. If you have a golden tree or mainline setup, and all your VBLs or offsite trees have to reverse integrate into the golden tree, this extra field would be overkill. That’s because you can trace the owner through the golden tree check-in. Having a field in which you would have to look up the VBL or offsite number would take just as long.

  The reality is that when you check a version number, you won’t care where the file came from. You’ll only care if it is a unique enough number to accurately trace the file to the source that created it. Most likely, you’ll already know the version number you’re looking for and you’ll just need to confirm that you’re using it.

• Component—If you break your whole project into separate components, should each component have its own identification number that would be included in the version string? No, similarly to the reasons in the previous bullet, you can track this information by the name of the binary or other information when checking the other properties of the file. This information would probably only come into play if you were filing a bug and you had other resources available to determine which component this file belonged to.
• Service Pack Build Number— If you’re doing daily builds of a service pack release, you should use the earlier example; increment the build number and keep the revision number at the current in-place file build number. This seems like a good argument for a fifth field, but it isn’t if the revision field is used properly.

DLL or Executable Versions for .NET (Assembly Versions)

This section applies to you only if you are programming in .NET.

When Microsoft introduced .NET, one of its goals was to get rid of DLL hell and all the extra setup steps I talk about later in this chapter. In reviewing where .NET is today, it looks like Microsoft has resolved the sideby-side DLL hell problem, but now the problem is “assembly version hell.” Without going into too much detail about the .NET infrastructure, let’s touch on the difference between file versioning and assembly versioning.

Assembly versions are meant for binding purposes only; they are not meant for keeping track of different daily versions. Use the file version for that instead. It is recommended that you keep the assembly version the same from build to build and change it only after each external release. For more details on how .NET works with these versions, refer to Jeffrey Richter’s .NET book. Don’t link the two versions, but make sure each assembly has both an assembly version and a file version when you right-click. You can use the same format described earlier for file versioning for the assembly version.

How Versioning Affects Setup

Have you ever met someone who reformats his machine every six months because “it just crashes less if I do” or it “performs better?” It might sound draconian, but the current state of component versioning and setup makes starting from scratch a likely solution to these performance issues, which are further complicated by spyware.

Most of the problems occur when various pieces of software end up installing components (DLLs and COM components) that are not quite compatible with each other or with the full set of installed products. Just one incorrect or incorrectly installed DLL can make a program flaky or prevent it from starting up. In fact, DLL and component installation is so important that it is a major part of the Windows logo requirement.

If you are involved in your product’s setup, or if you are involved in making decisions about how to update your components (produce new versions), you can do some specific things to minimize DLL hell and get the correct version of your file on the machine.

Installing components correctly is a little tricky, but with these tips, you can install your components in a way that minimizes the chance of breaking other products on your own.

Install the Correct Version of a Component for the Operating System and Locale

If you have operating system (OS)-specific components, make sure your setup program(s) check which OS you are using and install only the correct components. Also, you cannot give two components the same name and install them in the same directory. If you do, you overwrite the component on the second install on a dual-boot system. Note that the logo requirements recommend that you avoid installing different OS files if possible. Related to this problem is the problem caused when you install the wrong component or typelib for the locale in use, such as installing a U.S. English component on a German machine. This causes messages, labels, menus, and automation method names to be displayed in the wrong language.

Write Components to the Right Places

Avoid copying components to a system directory. An exception to this is if you are updating a system component. For that, you must use an update program provided by the group within Microsoft that maintains the component.

In general, you should copy components to the same directory that you copy the EXE. If you share components between applications, establish a shared components directory. However, it is not recommended that you share components between applications. The risks outweigh the benefits of reduced disk space consumption.

Do Not Install Older Components Over Newer Ones

Sometimes, the setup writer might not properly check the version of an installed component when deciding whether to overwrite the component or skip it. The result can be that an older version of the component is written over a newer version. Your product runs fine, but anything that depends on new features of the newer component fails. Furthermore, your product gets a reputation for breaking other products. We address the issue of whether it makes sense to overwrite components at all. But if you do overwrite them, you don’t want to overwrite a newer version.

“Copy on Reboot” If Component Is in Use

Another common mistake is to avoid dealing with the fact that you cannot overwrite a component that is in use. Instead, you have to set up the file to copy on reboot. Note that if one component is in use, you probably should set up all the components to copy on reboot. If you don’t, and if the user doesn’t reboot promptly, your new components could be mixed with the old ones.

Register Components Correctly; Take Security into Account

Sometimes setups don’t properly register COM components correctly, including the proxy and stub. Note that Windows CE requires that you also register DLLs. Note, too, that when installing DCOM components, you must be vigilant about permissions and security.

Copy Any Component That You Overwrite

It is smart to make a copy of any component that you overwrite before you overwrite it. You won’t want to put it back when you uninstall unless you’re sure that no product installed after yours will need the newer component—a difficult prediction! But by storing the component in a safe place, you make it possible for the user to fix his system if it turns out that the component you installed breaks it. You can let users know about this in the troubleshooting section of your documentation, the README file, or on your Web site. Doing this might not save a call to support, but it does at least make the problem solvable. If the component is not in use, you can move it rather than copying it. Moving is a much faster operation.

Redistribute a Self-Extracting EXE Rather Than Raw Components

If your component is redistributed by others (for instance, your component is distributed with several different products, especially third-party products), it is wise to provide a self-extracting EXE that sets up your component correctly. Make this EXE the only way that you distribute your component. (Such an EXE is also an ideal distribution package for the Web.) If you just distribute raw components, you have to rely on those who redistribute your components to get the setup just right. As we have seen, this is pretty easy to mess up.

Your EXE should support command-line switches for running silently (without a UI) and to force overwriting, even of newer components, so that product support can step users through overwriting if a problem arises.

If you need to update core components that are provided by other groups, use only the EXE that is provided by that group.

Test Setup on Real-World Systems

If you’re not careful, you can install all your setup testing on systems that already happen to have the right components installed and the right registry entries made. Be sure to test on raw systems, on all operating systems, and with popular configurations and third-party software already installed. Also, test other products to make sure they still work after you install your components.

Even Installing Correctly Does Not Always Work

Even if you follow all the preceding steps and install everything 100 percent correctly, you can still have problems caused by updating components. Why? Well, even though the new component is installed correctly, its behavior might be different enough from the old component that it breaks existing programs. Here is an example. The specification for a function says that a particular parameter must not be NULL, but the old version of the component ran fine if you passed NULL. If you enforce the spec in a new version (you might need to do this to make the component more robust), any code that passes NULL fails. Because not all programmers read the API documentation each time they write a call, this is a likely scenario.

It is also possible for a new version to introduce a bug that you simply didn’t catch in regression testing. It is even possible for clients to break as a result of purely internal improvements if they were relying on the old behavior. Typically, we assume that nothing will break when we update a component. In fact, according to Craig Wittenberg, one of the developers of COM who now works in the ComApps group at Microsoft, if you don’t have a plan for versioning your components in future releases, it is a major red flag for any component development project. In other words, before you ship Version 1, you need to have a plan for how you will update Version 1.1, Version 2, and beyond—besides how to bug-fix your updates.

Reference: The Build Master: Microsoft’s Software Configuration Management Best Practices

The post Why Worry About Versioning? – Versioning Complete guide appeared first on scmGalaxy.