People Management Coursework Example | Topics and Well Written Essays - 2000 words

People Management - Coursework Example The employer is expected to protect the employee’s interest and respect the role they play in the organization. On the other hand, the employee is expected to perform tasks as per the guidelines of the employer. In essence, psychological contract enhances a silent working environment and promotes respect between the employees and the employer. George (2009) argues that the basic feature of a psychological contract is the mutual obligation between the employer and the employee. Both parties to the contract have responsibilities and obligations to fulfill in relation to each other. Even though the content of the contract is not presented in writing, both parties have to know their responsibility as far as the subject matter is concerned. The obligations of each party are intangible and cannot be measured by the available conventional means. In this regard, the obligations are inbuilt, and it is only the parties to the contract who understands them. In essence, both the employer and the employee must perform their responsibilities accordingly to enhance quality performance and timely completion of tasks. Psychological contracts are unique in that the terms and conditions are a matter of personal perceptions. The psychological contract is complex since no available source can be found to ascertain that the contract was entered. Further complexity is observed in the fact that people’s perceptions change regular, and it is usually hard to comprehend what other people are thinking or planning to do. In addition, in case of a breach of the psychological contract, a third party cannot intervene since the contract is only known to the employee and the employer. Essentially, it is crucial to recognize that perception are sometimes seasonal and, therefore, understanding the content of the psychological contract by a third party can be extremely

Achievement Gap Research Paper Example | Topics and Well Written Essays - 3000 words

Achievement Gap - Research Paper Example that social equity cannot be attained in a society that still experiences achievement gap, and this is denotes that achievement gap is partly responsible for social inequity that prevails in numerous communities across the world. The assertions above infer that the elimination of achievement gap can create a scenario whereby every student will be equally competitive in the job market after finishing school and therefore, all of them will have equal chances in getting employment as well as improving their livelihoods. The possible benefits of eliminating achievement gap has necessitated and motivated numerous research studies that seek to analyse this problem and thereafter recommend a proper solution that can contribute to the body of knowledge currently been heaped by numerous educationists across the World. This present paper is a research project paper that seeks to contribute to the body of knowledge on achievement gap, is being continually developed by various educationists, psychologists, and other scholars across the World. In particular, the research will be field based, and problem based mini-research project on achievement gap. This mini research project will focus on the achievement differences between White and Hispanic students, especially those in similar socio-economic classes in Southern California. The research project will use the Erle Stanley Gardner Middle school in Temecula, and Menifee Valley Middle school both in California as the research case studies and the researcher will seek to describe and analyse achievement gap that exists in these two schools. In this regard, the research project will provide background information about the two schools, causes of the gap, and how it might effectively be eliminated. In the writings by Hernstein and Murray (1994), achievement gap is described as the persistent difference in terms of performance in educational measures such as standardized or common examinations, dropout rates, rate of college

Software Architecture Design Approach

Software Architecture Design Approach Rizwan Umaid Ali 1 Generate and Test as a Software Architecture Design Approach 1.1 About the Writer Len Bass from the Software Engineering Institute, CMU. Published in European Conference on Software Architecture 2009. 1.2 Introduction Software Architecture design has become a fundamental component of software development life cycle. As other components of life cycle testing the design of the architecture is important and relates directly to overall quality of the Software Application. 1.3 Problem To make a Software Architecture a design decision process that can test the design hypothesis, test quality of it and identify issues and rank them on the basis of priority. The process will develop test case on each step of design process. This will result a sequential process in which each design will be developed and tested and thus improving the overall design quality of software system. 1.4 Design Hypothesis Most designs are created in the context of an existing system, even it is created from scratch and not being modified. Consider this our initial hypothesis can come from following sources: The system we will modify or the new functionality we will add. A functionally similar system. A framework designed to provide services which will help in design process. A collection of legacy/open-source applications. 1.5 Establish Test Cases After we have our initial hypothesis we have to determine how to identify if design satisfies the quality benchmark expected from the application. For this we have to establish test cases and identify three sources for it. Identify perspectives which can be used to generate test cases. Identify architecturally significant requirements. View specific use cases. A number of use cases can be derived by thinking about specific architectural views. 1.6 Test Procedure Having the test cases of design hypothesis, following methods can be used to test the design and detect its shortcomings. Analytic models using quality attributes. Develop simulations of how design will support the test cases. Create prototype of initial design. Needs more effort but gives best result. 1.7 Test Result and Next Hypothesis The test result will either show that the design hypothesis passes all tests and fulfills the quality requirement or there are shortcomings. The quality attributes these shortcomings relate to should be identified first. We can use two approaches to alter the design. Apply architectural patterns to problems detected. Use architectural tactics to address for specific quality attributes. The updated/next hypothesis will go through the above process recursively until the design with required quality is achieved or the time allocated for the design process runs out. 1.8 Conclusion This paper presents a software architecture design process where we will test, validate and update our design until it reaches the quality benchmark. The architect of the software system can use this process to identify shortcomings and make decisions for alternative design structures. 2 SecArch: Architecture-level Evaluation and Testing for Security 2.1 About the Writer Sarah Al-Azzani and Rami Bahsoon from University of Birmingham. Published in Software Architecture (WICSA) and European Conference on Software Architecture (ECSA) in 2012. 2.2 Introduction Software architecture models or views are evaluated for detecting problems early in the software development lifecycle. We can detect critical security vulnerabilities at this stage and get a chance to improve quality at a very low cost. This paper presents methodology for detecting security vulnerabilities caused by implied scenarios and race conditions. 2.3 Problem Incorporating multiple views of an architecture and studying the communications between them and give ways analyze security concerns in concurrent systems. This will done by comparison between complete vs incomplete system models using two methods, one for detecting implied scenarios using behaviour models, and one for detecting race conditions using scenario diagrams. 2.4 Scenario-based specifications Scenario-based specifications are based on procedural-flow through components. Each scenario explains a partial view of the concurrent system. The scenario-based model will have following three properties: the composition of scenarios from multiple component views of the software system, the possible continuations between multiple scenario and the hidden implied scenarios. 2.5 Implied Scenarios Implied scenarios can be formed my dynamically combining two different scenarios together and provide an architectural flow for them is state representation. Below is an example of behavior model which is combining two different scenarios together. It uses an incremental algorithm for detecting inconsistent implied scenarios from sequence models. Figure 1 behavior model example 2.6 Detecting Race Conditions We can apply race condition scenarios to above model and identify security vulnerabilities. Below are the 3 possible cases. Â · Race Condition 1: disabling the server during authentication. Â · Race Condition 2: what happens when the user commits to buy an item while the server is being disabled. Â · Race Condition 3: what happens when the server is disabled while the user is logging off. Below are sequence diagrams for these three race conditions. Figure 2 Race Conditions 2.7 Conclusion This paper presented an incremental architecture evaluation method that merges behavior models with structural analysis for improved detection of inconsistencies. We examined the concept of implied scenarios and detection of race conditions. The writer also compared his proposed method with current industry practices and tested the on industry projects. He found that his method can give better results. The future work will focus on generating test cases to perform live testing on the system under test. 3 Towards a Generic Architecture for Multi-Level Modeling 3.1 About the Writer Thomas Aschauer, Gerd Dauenhauer, Wolfgang Pree from University of Salzburg. Published in European Conference on Software Architecture 2009. 3.2 Introduction Software architecture modeling frameworks are essential for representing architecture and their views and the viewpoints they are derived from. Conventional modeling approaches like UML do not have sufficient complexity to explain the models and meta-models (defining the models) of architecture. 3.3 Problem General purpose meta-models are used in the conventional modeling techniques, which are not sufficient for modern software models. Model driven architecture has to use more generic approach to describe multilevel architecture. 3.4 model-driven engineering and parameter generation Model-driven engineering (MDE) is method for managing complexities of developing large software intensive systems. The models in MDE are the main artifacts describing a system going under design process. This paper aims at developing a framework for model-driven generation of automation system configuration parameters using a testbed platform. The configuration parameters for the automation system can be generated automatically when a testbed model includes hardware and software components. Figure 3 Testbed configuration MDE 3.5 Presented Prototypical implementation The below example explain the modeling approach presented in this paper. Component is an example of the fixed meta-model elements represented as code in the environment. Different types of engines can now be either initiated using the Component, or by cloning the initial Engine and copying t to new engine. In the example, the Engine has two attributes, Inertia and MaxSpeed. In prototypical approach each element is an instance and must provide values to these attributes. Diesel and Otto represent two kinds of engines; since they are cloned from Engine, they receive copies of the attributes Inertia and MaxSpeed, as well as their values. Italics script is used to mark such copied attributes; grey text is used to express that the attribute values are kept unchanged. Figure 4 Meta-models example In Figure 4 DType represents a family of diesel engines. D1 finally is a concrete, physically existing member. 3.6 Conclusion This paper we presented applications of multi-level modeling in the domain of testbed automation systems and why conventional modeling is insufficient for our MDE requirements and how multi-level modeling can solve the representation issues. They presented an approach to represent models in much more detail with simple notations. 4 Automated reliability prediction from formal architectural descriptions 4.1 About the Writer JoËÅ" ao M. Franco, Raul Barbosa and MÂ ´ ario Zenha-Rela University of Coimbra, Portugal. Published in Software Architecture (WICSA) and European Conference on Software Architecture (ECSA) in 2012. 4.2 Introduction Assessment of quality attributes (i.e., non-functional requirements, such as performance, safety or reliability) of software architectures during design phase so early decisions are validated and the quality requirements are achieved. 4.3 Problem These quality requirements are most often manually checked, which is time consuming and error-prone due to the overwhelmingly complexity of designs. A new approach to assess the reliability of software architectures. It consists in extracting and validating a Markov model from the system specification written in an Architecture Description Language (ADL). 4.4 Reliability Prediction Process There are many different methods to achieve reliability prediction are known, each targeting diverse failure behaviours and different reliability assessment methods. The writer presented the below process for reliability prediction. Architecture and Module identification and their interactions. The Probability of Failure specified in terms of a percentage. Combining the architecture with the failure behaviour. Below is an example of batch sequential style state model using the Marov model. Figure 5 Markov model example Validation of the Process The validation of the process presented by the writer was done in two steps: Validity of Reliability Prediction Validity with different architectural styles. The validations were compared to previous research studies. It was found that results were similar proving that the mathematical models were accurate. 5 In Search of a Metric for Managing Architectural Technical Debt 5.1 About the Writer Robert L. Nord and Ipek Ozkaya from the Software Engineering Institute, CMU. Published in European Conference on Software Architecture 2009. 5.2 Introduction The technical debt is trade-off between short-term and long-term value. Taking shortcuts to optimize the delivery of features in the short term incurs debt, analogous to financial debt, that must be paid off later to optimize long-term success. This paper demonstrates a architecture focused and measurement based approach to calculate technical debt by describing an application under development. 5.3 Problem Technical debt thoroughly relays on system evaluation. An organization which has to evolve its system has to make sure if future development will not increase its debt and have a lower cost. In this paper the writer develops a metric that assists in strategically managing technical debt. 5.4 Architecture Debt Analysis We will analyze technical debt on two different paths. Both paths have different priorities. Path# 1: Deliver soon. To deliver a working version of the system quickly, the plan calls for making the minimum required effort at the beginning. Path #2: Reduce rework and enable compatibility. Requires an investment in infrastructure during the first deliveries. Cost compression of both paths is illustrated in the table below. Table 1 Cost Comparison We can calculate the total cost T with a function taking implementation cost and rework cost as input. T = F( Ci, Cr) For simplicity we consider the function sums both the cost up only. We can now compare the total cost with the cumulative cost. Table 2 Cost comparison with cumulative cost 5.5 Modeling Rework In Agile software development an important challenge is to give value to long term goals then short term. The cost of taking an architectural design decision today always has a lower cost than refactoring the design in future implementations. An organization should have the following prospective towards its technical debt. Focusing on short term goals puts the organization technical jeopardy, when the debt cannot be further handled. Using shortcuts can give success on short term until the rework costs starts to come and the cost and timeline becomes unmanageable. The architectural decisions requires active follow-ups and continuous cost analysis. This is to make sure that the design decision will make an impact in future costs of development. 5.6 Conclusion From this research we conclude that the future development of well-designed application has lower cost and is less tentative. Therefore the technical debt in lower if the architecture is well defined and fulfills quality attributes requirement. 6 Research Topic: Testing Software Architectural Changes and adapting best practices to achieve highest quality in a quantifiable manner. 6.1 Introduction We have looked into testing methodologies and design process and possible technical debt on software architecture. We now look how our technical debt will be effected if due t future requirements the architecture have to be changed. 6.2 Proposed Research Problem We will first Estimating Technical debt onExistingSoftware architecture and Software system. Then using Design changes and code changes for estimating technical debt and quality attributes. The prediction is made based on comparisons with similar change bursts that occurred in the Architecture. The views of software architecture will be used. This is applicable in Agile Development. 6.3 Types of changes We can classify each type of change in architecture by analyzing the overall impact of it on the architecture and possibilities of technical debt from it. We also assign a propagation value to each type of debt so that its estimated suavity can be quantified. Small architectural change in one or some views. Low Technical Debt increase (0.10) Addition of new architecture. Architecture for new functionality added. Medium Technical Debt increase (0.30) Small changes in several views. High Technical Debt increase (0.60) Massive architectural change is several views. High Technical Debt increase (0.80) 6.4 Proposed Solution After analyzing research papers and book ‘Software Architecture in Practice’, I can give following points on how the technical debt of new architecture can be managed. Compare updated architecture and see how the updates have increased the technical debt. Apply same test cases which were used in the initial software architecture. See how quality attributes are increased or decreased after the update. 6.5 Reduction of Technical Debt To reduce the technical debt after architectural changes following strategies can be adopted. 6.5.1 Refactoring Apply architectural patterns to improve several quality attributes. Use architectural tactics to address for specific quality attributes. 6.5.2 Retaining existing Architecture Models Continue the existing architecture in patterns. Search for Modifiability tactics already used. Stick to that tactics. 7 References [1] Len Bass: Generate and test as a software architecture design approach. WICSA/ECSA 2009 Page 309 – 312. [2] Sarah Al-Azzani and Rami Bahsoon. SecArch: Architecture-level Evaluation and Testing for Security. In 2012 Joint Working IEEE/IFIP Conference on Software Architecture (WICSA) and European Conference on Software Architecture (ECSA), pages 51 60, Aug. 2012. [3] Thomas Aschauer, Gerd Dauenhauer, Wolfgang Pree. Towards a Generic Architecture for Multi-Level Modeling. European Conference on Software Architecture 2009 Page 121 130. [4] J. Franco, R. Barbosa, and M. Zenha-Rela. Automated reliability prediction from formal architectural descriptions. In 2012 Joint Working IEEE/IFIP Conference on Software Architecture (WICSA) and European Conference on Software Architecture (ECSA), pages 302 -309, Aug. 2012. [5] R. Nord, I. Ozkaya, P. Kruchten, and M. Gonzalez-Rojas, In search of a metric for managing architectural technical debt, in 2012 Joint Working IEEE/IFIP Conference on Software Architecture and 6th European Conference on Software Architecture, 2012, pp. 91-100.

The Road Not Taken Vs. Mother To Son Essay -- essays research papers

Paths are Like Stairs   Ã‚  Ã‚  Ã‚  Ã‚  Although they portray two very different writing styles, Robert Frost’s â€Å"The Road Not Taken† and Langston Hughes’s â€Å"Mother to Son† have a few things in common, especially their meanings.   Ã‚  Ã‚  Ã‚  Ã‚  In â€Å"The Road not Taken† Frost speaks of a time in his life where he had to make a choice, a choice of which direction his life was about to go: â€Å"Two roads diverged in a yellow wood / And sorry I could not travel both† (1-2). â€Å"Mother to Son† also speaks of life in a metaphorical way, but as a staircase rather than two paths: â€Å"Well, son, I’ll tell you / Life for me ain’t been no crystal stair† (1-2).   Ã‚  Ã‚  Ã‚  Ã‚  Later in â€Å"The Road Not Taken† Frost describes the appearance of each road, one as being less traveled on than the other by people before him who had to make the same decision: â€Å"And looked down one as far as I could / Then took the other, just as fair / Because it was grassy and wanted wear† (4,6,8). â€Å"Mother to Son† takes it another step as to describe the staircase the mother had to climb. She explains how hard it was but also how she never gave up: â€Å"It’s had tacks in it / And splinters / And boards torn up / But all the time / I’se been a-climbin’ on† (3-5,8-9).   Ã‚  Ã‚  Ã‚  Ã‚  Ã‚  Ã‚  Ã‚  Ã‚  Ã‚  Ã¢â‚¬Å"The Road Not Taken† ends by giving a moral to us about Frost’s life and the path he did take. Although Frost doesn’t thoroughly explain the path he took, the reader ...

Kim Fuller Essay

In the early fall of 2002, Kim Fuller was employed as a district sales engineer for a large chemical firm. During a routine discussion with plant chemists, Fuller learned that the company had developed a use for the recycled material, in pulverized form, made from plastic soda pop bottles. Because the state had mandatory deposits all beverage bottles. Fuller realized that a ready supply of this material was available. All that was needed was an organization to tap that bottle supply, grind the bottles, and deliver the pulverized plastic to the chemical company. It was an opportunity Fuller had long awaited—a chance to start a business. In November 2002 Fuller began checking into the costs involved in setting up a plastic bottle grinding business. A used truck and three trailers were acquired to pick up the empty bottles. Fuller purchased one used grinding machine but had to buy a second one newï ¼â€ºSupplies and pans necessary to run and maintain the machines were also purcha sed. Fuller also purchased a personal computer with the intention of using it to keep company records. These items used $65,000 of the $75,000 Fuller had saved and invested in the company. A warehouse costing $162,000 was found in an excellent location for the business. Fuller was able to interest family members enough in this project that three of them, two sisters and a brother, invested $30, 000 each. These funds gave Fuller the$50,000 down payment on the warehouse. The bank approved a mortgage for the balance on the building. In granting the mortgage, however, the bank 0fficial suggested that Fuller start from the beginning with proper accounting records. He said these records would help not only with future bank dealings but also with tax returns and general management of the company. He suggested Fuller find a good accountant to provide assistance from the start, to get things going on the right foot. Fuller’s neighbor, Marion Zimmer, was an accountant with a local firm. When they sat down to talk about the new business, Fuller explained, â€Å"I know little about keeping proper records.† Zimmer suggested Fuller should buy an â€Å"off-the-shelf† accounting system software package from a local office supply retailer. Zimmer promised to help Fuller select and install the package as well as learn how to use it. In order to select the fight package for Fuller’s needs, Zimmer asked Fuller to list all of the items purchased for the business, a11 of the debts incurred, and the information Fuller  would need to manage the business. Zimmer explained that not al l of this information would be captured by the accounting records and displayed in financial statements. Based on what Fuller told Zimmer, Zimmer promised to create files to accommodate accounting and non-accounting information that Fuller could access through the company’s personal computer. As Fuller’s first lesson in accounting, Zimmer gave Fuller a brief lecture on the nature of the balance sheet and income statement and suggested Fuller draw up an opening balance sheet for the company. Confident now that the venture was starting on solid ground, Kim Fuller opened the warehouse, signed contracts with two local bottling companies, and hired two grinding machine workers and a truck driver. By February 2003 the new firm was making regular deliveries to Fuller’s former employer. Questions 1. What information will Fuller need to manage the business? Classify this information in two categories: accounting information and non-accounting information. 2. See what you can do to draw up a beginning of business list of the assets and 1iabilities of Fuller’s company making any assumptions you consider useful. How should Fuller go about putting a value on the company’s assets? Using your values, what is the company’s opening owners’ equity? 3. Now that Fuller has started to make sales, what information is needed to determine â€Å"profit and loss†? What should be the general construction of a profit and loss analysis for Fuller’s business? How frequently should Fuller do such all analysis? 4. What other kinds of changes in assets, 1iabilities, and owners’ claims will need careful recording and reporting if Fuller is to keep in control of the business?

The Hunters: Phantom Chapter 2

Dear Diary, I AM HOME! I can hardly dare to believe it, but here I am. I woke with the strangest feeling. I didn't know where I was and just lay here smelling the clean cotton-and-fabric-softener scent of the sheets, trying to figure out why everything looked so familiar. I wasn't in Lady Ulma's mansion. There, I had slept nestled in the smoothest satin and softest velvet, and the air had smelled of incense. And I wasn't at the boardinghouse: Mrs. Flowers washes the bedding there in some weird-smelling herbal mixture that Bonnie says is for protection and good dreams. And suddenly, I knew. I was home. The Guardians did it! They brought me home. Everything and nothing has changed. It's the same room I slept in from when I was a tiny baby: my polished cherry-wood dresser and rocking chair; the little stuffed black-and-white dog Matt won at the winter carnival our junior year perched on a shelf; my rolltop desk with its cubbyholes; the ornate antique mirror above my dresser; and the Monet and Klimt posters from the museum exhibits Aunt Judith took me to in Washington, DC. Even my comb and brush are lined up neatly side by side on my dresser. It's all as it should be. I got out of bed and used a silver letter opener from the desk to pry up the secret board in my closet floor, my old hiding place, and I found this diary, just where I hid it so many months ago. The last entry is the one I wrote before Founder's Day back in November, before I†¦ died. Before I left home and never came back. Until now. In that entry I detailed our plan to steal back my other diary, the one Caroline took from me, the one that she was planning to read aloud at the Founder's Day pageant, knowing it would ruin my life. The very next day, I drowned in Wickery Creek and rose again as a vampire. And then I died again and returned as a human, and traveled to the Dark Dimension, and had a thousand adventures. And my old diary has been sitting right here where I left it under the closet floor, just waiting for me. The other Elena, the one that the Guardians planted in everyone's memories, was here all these months, going to school and living a normal life. That Elena didn't write here. I'm relieved, really. How creepy would it be to see diary entries in my handwriting and not remember any of the things they recounted? Although that might have been helpful. I have no idea what everyone else in Fell's Church thinks has been happening in the months since Founder's Day. The whole town of Fell's Church has been given a fresh start. The kitsune destroyed this town out of sheer malicious mischief. Pitting children against their parents, making people destroy themselves and everyone they loved. But now none of it ever happened. If the Guardians made good on their word, everyone else who died is now alive again: poor Vickie Bennett and Sue Carson, murdered by Katherine and Klaus and Tyler Smallwood back in the winter; disagreeable Mr. Tanner; those innocents that the kitsune killed or caused to be killed. Me. All back again, all starting over. And, except for me and my closest friends – Meredith, Bonnie, Matt, my darling Stefan, and Mrs. Flowers – no one else knows that life hasn't gone on as usual ever since Founder's Day. We've all been given another chance. We did it. We saved everyone. Everyone except Damon. He saved us, in the end, but we couldn't save him. No matter how hard we tried or how desperately we pleaded, there was no way for the Guardians to bring him back. And vampires don't reincarnate. They don't go to Heaven, or Hell, or any kind of afterlife. They just†¦ disappear. Elena stopped writing for a moment and took a deep breath. Her eyes fil ed with tears, but she bent over the diary again. She had to tel the whole truth if there was going to be any point to keeping a diary at al . Damon died in my arms. It was agonizing to watch him slip away from me. But I'll never let Stefan know how I truly felt about his brother. It would be cruel – and what good would it do now? I still can't believe he's gone. There was no one as alive as Damon – no one who loved life more than he did. Now he'll never know – At that moment the door of Elena's bedroom suddenly flew open, and Elena, her heart in her throat, slammed the diary shut. But the intruder was only her younger sister, Margaret, dressed in pink flower-printed pajamas, her cornsilk hair standing straight up in the middle like a thrush's feathers. The five-year-old didn't decelerate until she was almost on top of Elena – and then she launched herself at her through the air. She landed squarely on her older sister, knocking the breath out of her. Margaret's cheeks were wet, her eyes shining, and her little hands clutched at Elena. Elena found herself holding on just as tightly, feeling the weight of her sister, inhaling the sweet scent of baby shampoo and Play-Doh. â€Å"I missed you!† Margaret said, her voice on the verge of sobbing. â€Å"Elena! I missed you so much!† â€Å"What?† Despite her effort to make her voice light, Elena could hear it shaking. She realized with a jolt that she hadn't seen Margaret – really seen her – for more than eight months. But Margaret couldn't know that. â€Å"You missed me so much since bedtime that you had to come running to find me?† Margaret drew slightly away from Elena and stared at her. Margaret's five-year-old clear blue eyes had a look in them, an intensely knowing look, that sent a shiver down Elena's spine. But Margaret didn't say a word. She simply tightened her grip on Elena, curling up and letting her head rest on Elena's shoulder. â€Å"I had a bad dream. I dreamed you left me. You went away.† The last word was a quiet wail. â€Å"Oh, Margaret,† Elena said, hugging her sister's warm solidity, â€Å"it was only a dream. I'm not going anywhere.† She closed her eyes and held on to Margaret, praying her sister had truly only had a nightmare, and that she hadn't slipped through the cracks of the Guardians' spel . â€Å"Al right, cookie, time to get a move on,† said Elena after a few moments, gently tickling Margaret's side. â€Å"Are we going to have a fabulous breakfast together? Shal I make you pancakes?† Margaret sat up then and gazed at Elena with wide blue eyes. â€Å"Uncle Robert's making waffles,† she said. â€Å"He always makes waffles on Sunday mornings. Remember?† Uncle Robert. Right. He and Aunt Judith had gotten married after Elena had died. â€Å"Sure, he does, bunny,† she said lightly. â€Å"I just forgot it was Sunday for a minute.† Now that Margaret had mentioned it, she could hear someone down in the kitchen. And smel something delicious cooking. She sniffed. â€Å"Is that bacon?† Margaret nodded. â€Å"Race you to the kitchen!† Elena laughed and stretched. â€Å"Give me a minute to wake al the way up. I'l meet you down there.† I'll get to talk to Aunt Judith again, she realized with a sudden burst of joy. Margaret bounced out of bed. At the door, she paused and looked back at her sister. â€Å"You real y are coming down, right?† she asked hesitantly. â€Å"I real y am,† Elena said, and Margaret smiled and headed down the hal . Watching her, Elena was struck once more by what an amazing second chance – third chance, real y – she'd been given. For a moment Elena just soaked in the essence of her dear, darling home, a place she'd never thought she'd live in again. She could hear Margaret's light voice chattering away happily downstairs, the deeper rumble of Robert answering her. She was so lucky, despite everything, to be back home at last. What could be more wonderful? Her eyes fil ed with tears and she closed them tightly. What a stupid thing to think. What could be more wonderful? If the crow on her windowsil had been Damon, if she'd known that he was out there somewhere, ready to flash his lazy smile or even purposely aggravate her, now that would have been more wonderful. Elena opened her eyes and blinked hard several times, wil ing the tears away. She couldn't fal apart. Not now. Not when she was about to see her family again. Now she would smile and laugh and hug her family. Later she would col apse, indulging the sharp ache inside her, and let herself sob. After al , she had al the time in the world to mourn Damon, because losing him would never, ever stop hurting.