|- Ayhan Dev -|

We wrote a sample Dockerfile. You can use it in your projects. If you need something that is not listed, please email me at [email protected]. github.com/ayhan-dev/Docker.file

Why is private inheritance needed in C++? With public inheritance, everything is obvious: you create a base [interface] class, build a hierarchy from it, and get the well-known "is a". For example, ASTs are often built on them (from what I have seen) so that each node supports certain actions that can be overridden in derived classes. Then you can accept a pointer/reference to the base class and perform the necessary manipulations in its terms. If the derived classes are implemented with respect to LSP (Liskov Substitution Principle), then we will be happy. This approach is as close as possible to what we use in other areas of knowledge. Cliched examples - in mathematics, we have definitions that are also something else (classic example - a square is also a rectangle, but there are pitfalls). Or in biology, where there is a basic class like "living thing" inherited by kingdoms... and so on. Again, using the example of birds and penguins, it can be noted that not always familiar invariants like "birds fly" are upheld. 🐦🐧 There are many examples, but sometimes the design is so-so. But why is private inheritance needed? For what? This is essentially composition, which can also be done using a class field. From the examples known to me: - "Trick" (more of a hack) with merging stateless classes, which should have a non-zero size, but they can be stacked on top of each other and possibly (no guarantee) result in a smaller size. And now it, let's say, fits into the cache line of the target system. - Exposing a public method of the base class. If the derived class should already have an implemented method, you can bring it into scope and enjoy life. - Overriding virtual functions of the base class. Overall, not found anything much shorter and working better:

class Name {
  std::string name_;
  virtual std::string prefix() { return "Great "; }
public:
  Name(auto name) : name_{name} {}
  std::string get() { return name_; }
  std::string makeBetter() {
    name_ = prefix() + name_;
    return name_;
  }
};

class FullName : Name {
  std::string prefix() override { return "The "; }
public:
  FullName(auto name, auto suffix) : Name{name + " " + suffix} {}
  using Name::get;
  using Name::makeBetter;
};

int main() {
  using std::string_literals::operator""s;
  FullName my{"Cat"s, "Meow"s};
  std::cout << my.get() << std::endl;
  std::cout << my.makeBetter() << std::endl;
  return 0;
}

Now we have everything that was under those names in the original class. An alternative would be to rewrite methods from scratch that would do the same with a field... and then keep them consistent... Sorry for the long response!

یه ریپوزتوری برای گشادا Docker file اماده قرار می‌دم با تنظیمات... - اولی برای لاراول هست - و star , follow یادتون نره 😑 - کسی نیاز داشت بدید بهش - هر روز یه Dockerfile جدید Nodejs, .net , go. ... github.com/ayhan-dev/Docker.file

⚡️ 4 Github Repositories for preparing for 4 different types of software development interviews: 1. System design interviews: https://github.com/ashishps1/awesome-system-design-resources 2. Low-level design interviews: https://github.com/ashishps1/awesome-low-level-design 3. Programming interviews: https://github.com/ashishps1/awesome-leetcode-resources 4. Behavioral interviews: https://github.com/ashishps1/awesome-behavioral-interviews < #Ai > 🇹🇷

یه سرویس ابری | فضای ابری و DNS و هاست جهت بالا اوردن سایت با دیتابیس و ربات SEO , BRU , ONNE و.. و امکانات خصوصی (اشتراکی) | تحت وب تاریک به یه اسپانسر تبلیغاتی و... نیاز دارم کسی بود پیام بده 😄 ( 15% سهام بهش میدم مابقی برای خودمه (باز بستگی به شرایط داره)) در صورت بود پیام بدید @Dev_Devils

#A_2024 - #Dev_2024 - #A_3 Lessons of 50 Years of Software Development Lesson 3. Interests of all parties intersect in requirements The success of a project is the satisfaction of all requirements and adherence to all constraints that define the expectations of stakeholders. The development team must identify the stakeholders and their interaction order. A stakeholder is any individual or group of people actively involved in the project, affected by it, or capable of influencing its progress. Typically, this includes the development team, clients, end-users, indirect users, regulatory bodies, and so on. Analysis The project team should identify potential stakeholder groups in advance. The list may be long and require efforts, but it's better than ignoring critically tuned communities and making corrections in the later stages of the project. To simplify requirements analysis, segment users into groups with different sets of needs. Users can even be hardware devices or other software. Identify individuals who can provide requirements on behalf of these components. There may also be indirect product users. For example, recipients of a company's annual reports do not interact directly with the software, but they are key stakeholders. It is also necessary to identify classes of undesirable users who should not have the ability to use the system. For instance, hackers are not stakeholders (do not define requirements or constraints), but their malicious intentions must be anticipated and thwarted. For each stakeholder group, describe: 1. Who are they? So that all project participants understand who they are. 2. How interested are they? How much the project's outcomes will impact the group and their desire to participate in the project. Their expectations, interests, concerns, and constraints. 3. What influence do they have on the project? What decisions they can and cannot make. Who has the most influence? Special attention to groups showing the greatest interest and exerting the most influence. 4. Who is best to talk to? Representatives of each group with whom you need to work. They should be authoritative sources of information. 5. Where are they? It's easier to obtain information if there is direct access to the group's representatives. Alternatively, consider the communication process. 6. What do we need from them? Information, decisions, and data needed from each group. Some groups will impose restrictions on the project, such as: - financial, time, and resource constraints; - applicable policies, norms, and standards (business rules); - compatibility with other products, systems, or interfaces; - legal or contractual requirements; - certification requirements; - product capability restrictions (what should not be included in the product). 7. What do they need from us? Some may need to be informed about issues, while others may need requirements review. 8. How and when to interact with them? 9. Which parties are most important in conflict resolution? When resolving conflicts and making important decisions, evaluate which result best aligns with the project's goals. Analyze the influence and interests of the parties, don't wait for the first conflict to escalate. We're all on the same side Identify decision-makers. Sometimes it's one person (sponsor or product owner). More often, the correct groups of people from different areas will need to be identified for decision-making. Group decisions take more time but better reflect all interests aligned with the project's goals. Objectives, constraints, and other business requirements are usually formalized in a vision statement. It's not always possible to satisfy everyone with project results. Building cooperative relationships among key stakeholders is crucial for success. From the beginning, communication should be based on mutual respect.

#A_2024 - #Dev_2024 - #A_2 Lessons of 50 Years of Software Development Lesson 2. The main result of requirement development is a shared vision and understanding The tangible result of requirement development is a document in some stored form. Usually, this is a written document, often referred to as software requirements specification or business requirements. Alternatively, requirements can be documented as cards, stickers on a board, diagrams, acceptance tests, or a combination of all these. However, the most important results of requirement development are a shared vision (understanding) and agreement among stakeholders regarding the solution that will be created by the project team. By achieving this understanding, it can be checked whether the proposed scope and budget of the project match the necessary capabilities and characteristics of the solution. Managing expectations is an important part of project management. Requirement development aims to form common expectations among stakeholders. Requirements specifications contain information about agreement specifics. This coordinates all project-related activities: - work funded by the project sponsor; - a solution that customers expect will help them achieve business goals; - software tested by testers; - a product that marketing and sales departments will offer to the world; - plans and task lists created by project managers and development teams. It is often difficult to determine if several people understand something as complex as a software development project in the same way. These differences can lead participants to pursue conflicting goals. Articulating the concept (vision statement) defines the overall strategic goal that all project participants should strive for. It helps achieve a common understanding and consistent expectations. Here is an approximate template for a vision statement: For [target customers] Who [statement of business needs or opportunities] It is supposed to create [product or project name] Being [type of product or project] Allowing [core product features; key benefits it will provide; compelling reason for purchasing the product or implementing the project] Unlike [current reality or alternative products] Our product [brief summary of the main advantages of this product compared to current reality or competitors' products] If your project does not have a vision statement, it is never too late to write one. Often, it is important for representatives of different stakeholders to write vision statements separately. Later on, by comparing these statements, it can be seen whether stakeholders have reached a common understanding of where the project is heading. The presence of discrepancies suggests that team members need to work on aligning their expectations. The vision statement defines the overall strategic goal that all project participants should strive for. If the vision changes during project work, the client should inform everyone affected by these changes to ensure that people still have a unified understanding of the requirements. The vision statement does not replace requirements specifications, but it sets a starting point to ensure that the requirements voiced to the team align with this vision.

#A_2024 - #Dev_2024 50 Years of Software Development Lessons Lesson 1. If you incorrectly define the requirements, no matter how well you do the rest of the work The IT department embarked on creating a new information system for their company. Developers believed they understood the requirements perfectly and proceeded without surveying users. However, the users' reaction to the completed system was: "Seriously, where is our application?" They categorically rejected the system. Failure to engage with users, which helps ensure the correct understanding of requirements, was a serious oversight. Ultimately, the developers redesigned the system, this time carefully listening to the users. It was a costly lesson about the importance of involving the client in defining requirements. Requirements are the foundation for all subsequent work on a project. Numerous studies have shown that effective development and timely requirement communication are crucial factors for the success of any project. Conversely, inadequate project vision, incomplete and inaccurate requirements, as well as changing project requirements and goals, are common causes of failure. In the absence of thorough requirements analysis, stakeholders may be surprised by what the development team proposes. Such software surprises often turn out to be unpleasant. When? It is unrealistic to have a complete set of requirements before starting implementation. New ideas, changes, and corrections will always emerge that you must consider in your development plans. However, for any part of the system you are creating, it is essential to have as complete and accurate requirements as possible. Either plan for refinements after implementation is complete. In Agile projects, an additional requirements validation stage is provided. The further the initial requirements stray from what customers actually need, the more refinements will be needed. Considering that there is always room for improvement, you will never be able to meet requirements perfectly. However, the agreed-upon scope of development demands that you do everything correctly, otherwise success is unlikely. If you are creating an innovative product, i.e., something that no one has ever done before, you are unlikely to get everything right on the first try. The first attempt essentially involves testing hypotheses and defining requirements experimentally. However, ultimately, experiments will help you understand the capabilities and characteristics of the new product—its requirements. How? Nothing can replace ongoing interaction with customers. You cannot simply have a meeting at the very beginning and then tell customers, "We'll call you when we're done." Ideally, the team should stay in touch with customer representatives throughout the project development. Developers will have many questions and points that require clarification. Team members must outline general requirements at early stages and gradually refine them later on. The team needs reliable frequent feedback from users to confirm the correct understanding of requirements and proposed solutions. It is not always easy to persuade customers to engage in such close interaction. One way to convince a client is to provide examples of problems that arose due to insufficient client involvement in product development. Even better is to share experiences where cooperation with customers has paid off. Another method is to offer a clear plan for interactions to refine requirements, which may include informal discussions, meetings, requirement reviews, and the approval of sketches, prototypes, and release sequences. Customers are more likely to positively assess a project and be more willing to contribute if they see progress, such as through periodic releases of new versions of working software. Sometimes it is difficult to persuade clients to accept an updated software system. Client representatives who have worked with the development team, understand ing the essence of the innovations and their necessity, can help facilitate this transition.