This is the Linux CLI-Command Line Interface command to Find all the occurrences of a string and Replace it with desired string in all the files in the directory. This is very powerful and very fast. So do take all the precautions before executing this command. The command is grep -rl STRING1 SOMEDIR/ | xargs sed -i 's/STRING1/STRING2/g' Explanation: The grep will search for the string 'STRING1' and pipe it to the sed command for the replacements. The sed command replaces the STRING1 with STRING2 in all the occurrences of the STRING1.
Until recently, the only practical way to do package management for PHP was to use PEAR (PHP Extension and Application Repository). But PEAR’s long been regarded as difficult to work with and it’s crowded with outdated and unmaintained software. Many of the more popular PHP frameworks had their own private package-management systems — CakePHP’s Bakery, CodeIgniter’s Sparks — but little or nothing for PHP as a whole.
The biggest change to come along in this space is Composer, which takes notes from Node.js’s NPM system and Ruby’s Bundler. Packages are tracked on a project-by-project basis so that it’s easy to determine which packages are needed for a given project and can be installed automatically. It works with a repository named Packagist, which already includes many common PHP apps, frameworks, and components.
Composer is a tool for dependency management in PHP. It allows you to declare the dependent libraries your project needs and it will install them in your project for you. Composer is not a package manager. Yes, it deals with “packages” or libraries, but it manages them on a per-project basis, installing them in a directory inside your project. By default it will never install anything globally. Thus, it is a dependency manager.
Packagist is the main Composer repository. It aggregates all sorts of PHP packages that are installable with Composer.
Women in open source are making revolutionary contributions and paving the way for others as they innovate in the field. In tandem with the Grace Hopper conference happening this week, I put together a healthy dose of knowledge on the subject with a quick spotlight on five talented women in open source. A few of them give advice on working in tech. Click me for more.
In part 1 of this blog series, we discussed on how business and application related considerations affect selection of SDLC methodology
Part I: http://www.infosysblogs.com/application-services/2013/09/striking_the_balance_waterfall.html
In this blog post, we will continue looking for impact of agile team execution location as well as what pre requisites are considered while team is formed for execution, paving way for inclination to type of methodology preferred.
Agile teams will be more productive if all the team members are collocated. Work needs to divided into vertical slicing as against traditional horizontal slicing as per requirements, design, development, testing work. If teams have to be distributed, they needs to be encouraged to become self-sufficient and self-organizing with provision of additional enablement needs like better communication and collaboration infrastructure, some means of product owner access as well as well thought out automation roadmap.
If teams can arrange for dedicated collaborative team workspace, it will help facilitate face-to-face communication, encourage informal communication through adequate display area within workspace show and tell way of work using boards, drawing sheets, stationery. It is under such a well networked environment that agile works at its best. These initiatives will motivate the teams and triggers work environment change, enabling mind set change.
If teams don’t prefer to change their ways of working, waterfall approach can be preferred and projects can continue as business as usual (BAU) in existing cubicle workspace.
In an environment where organization focus is on factory standard processes, leadership expects project team members to understand and implement common processes to their personal work and project success, demands process/compliance heavy command and control phase gate approach, there is a separate process management staff or PMO who maintain process documentation, waterfall can be chosen as more suitable methodology as agile suggest more leaner approach for documentations.
In an environment, where teams can avail agile coaching and training in the areas of refactoring, pair programming, code review, test first approaches like test driven development (TDD), acceptance test driven development (ATDD), behavior driven development (BDD), agile process trainings such as scrum , lean ,Kanban, agile adoption is much better off. Whole team should get training along with role specific trainings such as product owner (PO), scrum master (SM). Additional trainings such as cross functional team behavior, generalist approach, facilitation skills, problem solving, team ownership, Whole system approach will enhance agile projects success manifold.
If project team can be formed as cross functional teams including architects, BA’s ,designers, developers, testers along with release and configuration stream representatives for broader views and collective decision making, agile approach will be effective.
A waterfall project requires specialized teams working using a phase-gate approach.
Agile demands long lived teams with minimal attrition rates to retain cohesive teams of individuals with core competencies and multiple cross-functional skills. HR policies should be able to handle agile recruitment, benefits and compensations, rewards and recognition, and appraisals.
A centralized HR department that follows organizational policies and procedures for people management will be more inclined towards waterfall approach.
For agile teams to be effective, team members must be fully allocated to the project instead of allocating percentages. Team members must be retained within iterations as well as for multiple versions of product development making team long lived. This ensures that the project delivers on its iteration level commitments. It also makes the team/ resources own the iteration results and sustain a predictable team velocity.
If project is desiring to have shared resources among projects for maximum allocation and utilization, naturally waterfall may be more adapt.
For Agile to be effective, the team needs to be empowered to perform faster and better and be accountable for its results. Teams that are not empowered are unable to make certain decisions such as providing a fresh estimate forecast at the beginning of each iteration/ sprint and providing revised estimate forecast. This is needed to ensure that the team gains more visibility on what needs to be done.
It is common to have a matrix functional organization where resources are grouped temporarily for the duration of project. This necessitates multiple lines of reporting, making teams less empowered and more geared towards waterfall approach.
In an agile environment, a scrum master or iteration manager should be available who will identify or help the team to overcome obstacles. SM/IM needs the authority to act in the interest of the team, represent the team, and eliminate disturbances.
In a matrix organizational role, the project manager handles the project with command and control and can follow waterfall.
In an agile environment, team members should be empowered with several degrees of freedom to define problems and handle resolution. If organization rely heavily on policies and procedures and expects the team also comfortable and empowered with policy compliance with clear hierarchies of responsibilities and authorities are existing, waterfall is better suited.
Team Location, work distribution, workspace design, team composition, coaching and training are differentiators for the choice of either agile or waterfall.
In the coming post, I will put forward importance of tooling in deciding either waterfall or agile approach.