Synchronizing Threads for Professor and Students
Implementation of procedures to synchronize threads for a professor and students using mutex, condition variables, and semaphores. The procedures ensure that the professor wakes up when students visit the office to ask questions and that exactly one student interacts with the professor at a time.
Download Presentation
Please find below an Image/Link to download the presentation.
The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author.If you encounter any issues during the download, it is possible that the publisher has removed the file from their server.
You are allowed to download the files provided on this website for personal or commercial use, subject to the condition that they are used lawfully. All files are the property of their respective owners.
The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author.
E N D
Presentation Transcript
How To: Modernizing Legacy Web Applications
What is legacy? #!/usr/bin/perl =head1 DESCRIPTION =cut print "Content-type: text/plain\n\n"; for my $var ( sort keys %ENV ) { printf "%s = \"%s\"\n", $var, $ENV{$var}; }
What is legacy? Old? Different tech? Different architecture? Different design team? At the end of the day, a legacy system is any system that still has value, but has entered into decline. Increased support issues Longer development timelines Increased costs
Why Upgrade? Risk Out of Support No one left who understands it Support nightmare Business-Driven Inflexible Ugly Expanding business Inherited from other Expense Older systems, older hardware Limited hosting options Extended Support Contracts
Why Experts Say We Change 100% 90% 80% 70% Not this! 60% This! 50% 40% 30% 20% 10% 0% Flexible High Cost Faster TtM No Doc New Biz Vendor Failure Very Weak Weak Strong Very Strong Khadka, Batlajery, Saeidi, Jansen, Hage 2005
How To: Making the Plan Set a High Level Vision Decide to build new or build on current Big Bang or parallel run? Choose technologies Figure out what you re doing with existing assets Data? Reports? Set Goals (and expectations!) When do you need MVP? When do you want MVP? When are you done?
The Plan 1. Vision 2. Goals 3. Roll-Out Approach 4. Stack
How To: Teams Who s running this show? Staff up Do you have the right skill sets? Do you have to maintain the old system actively? If you need to staff up, what happens to the team after you re done? Skills Do you have the right architect? How will training work? New stuff as a reward Be careful this is a fine line
The Plan 1. Vision 2. Goals 3. Roll-Out Approach 4. Stack 5. Team Structure 6. Training & Augmentation
How To: Requirements How it works now is not a requirement Leverage Old Hands , supplement with new users Archaeology vs Requirements Tools vs Manual SME Experience vs Requirements Analysis You re not rebuilding the old system You re building a new system that does some of the same things as the old system, but is focused on enabling the way the business works now
The Plan 1. Vision 2. Goals 3. Roll-Out Approach 4. Stack 5. Team Structure 6. Training & Augmentation 7. Archaeology 8. Requirements Analysis
How To: Execute Foundation Domain Environments Data Model Scaffolding Data Access Identity Security System Wide Needs (Logging, Audit, etc) Then features Migration Data & Reports Integration Points
The Plan 1. Vision 9. Build Foundations 2. Goals 10. Build Feature/Function Iterate 3. Roll-Out Approach 11. Migrate Systems 4. Stack 5. Team Structure 6. Training & Augmentation 7. Archaeology Iterate 8. Requirements Analysis
How To: Support & Development Concurrent Support & Operations? Split teams? Pilot groups Cutoff Periods Pitfalls Late communication Missed communication Unclear feedback channels
The Plan 1. Vision 9. Requirements Analysis 2. Goals 10. Build Foundations 3. Roll-Out Approach 11. Build Feature/Function Iterate 4. Stack 12. Update Stakeholders 5. Inform Stakeholders 13. Migrate Systems 6. Team Structure 14. Migrate Users 7. Training & Augmentation 8. Archaeology Iterate
Troubleshooting: Domain Evolution Domains change over time Especially true when dealing with legacy apps Example: Check Deposit DDA Customer Customer What goes wrong? Modern design for archaic process Business layer that doesn t support front end Missed opportunities deposits deposits gives gives update Check Check Check 21 System Y ellow Box Teller ATM put in transmit verifies verifies
Troubleshooting: Architecture Mismatch Containers Consider integration points Create bottelnecks/SPOFs? Are container-specific data stores viable? Back-end process dependencies Service vs Microservices Resist the urge to reuse services if migrating to microservices Inconsistent architecture Incompatible data formats/schemas
Case Study: Regional Bank Upgrade Situation: Convert Smalltalk thick client to JEE web What went right Great communication with the business Willingness to truly build a new platform, not just upgrade the old platform Good training and strong architecture support What went wrong Not enough coordination between technology teams Insistence on keeping antiquated ORM/DAL
Case Study: Top 10 Commercial Bank Replatform Situation: CORBA/JSE Web App to JEE Web What went right Strong support from business leadership Strongly defined non-functional requirements What went wrong Poor time estimation and loose project management No real functional requirements definition Insufficient training & architecture oversight
Case Study: Top 10 Consumer Bank Replatform Situation: Multiplatform SOAP to Multiplatform Microservices/REST What went right Well-defined vision and objective Strong architectural oversight What went wrong Timeline too long needs and requirements changed over course of effort Overly committed to pre-existing service/data models
Case Study: Multinational Insurance Upgrade Situation: ASP.Net to Angular What went right Technology teams upgraded skill sets quickly Strong business & technology partnership What went wrong Requirements left to just like it works today Architect brought a dated technology viewpoint
Thanks! Josh Street Twitter: @rjstreet
