Science | Ксения Леонтьева

Creating a report

Thu, 02 Nov 2023 00:00:00 +0000

Report structure

According to the generally accepted standard, any research work must necessarily contain the following elements:

title page,
abstract,
introduction,
theoretical part,
main part,
conclusion.

The standard also recommends including the following elements:

list of performers,
content,
normative references,
definitions,
designations and abbreviations,
list of sources used,
applications.

Content of main elements of the report

Title page. The first page of work is drawn up strictly according to the model, which is usually given in teaching aids. It not only requires you to indicate elements such as the name of the educational institution, type of work and information about the performer, but also arrange them in strict accordance with the standards.

Abstract. The abstract is essentially a summary of your entire report and contains a number of statistical information. It must indicate the number of parts, pages of work, illustrations, appendices, tables, used literary sources and appendices. Here is a list of keywords of the work and the actual text of the abstract. The latter implies the main elements of work from set goals to results and recommendations for their implementation.

Introduction. The introduction of a standard report usually states the goals of the research being conducted and the tasks that will help achieve the goals. It is also necessary to write a detailed introduction with proof of the relevance and novelty of the topic being studied. In the introduction, it is necessary to provide an assessment of the current state of the problem under consideration and justify the need for its solution.

Theoretical part. The content of the theoretical part depends on the discipline in which the laboratory work is being done. This may be a description of formulas, theorems, measuring instruments and techniques, or the history of studying the problem. All this is presented briefly and as briefly as possible.

Main part. This section of the report should reflect the essence of the work, describe its methodology and the results obtained. The main part contains the following elements:

goals of the research;
tasks, the implementation of which will help achieve the goals;
progress of work, which describes the actions performed;
other sections provided for in the teaching materials for the discipline being studied.

Conclusion. In this part of the report, you need to draw conclusions based on the results obtained during the work. To do this, it is assessed how fully the assigned tasks have been completed. Complex work may also contain other elements, for example, recommendations for further application of the results of the work performed.

Markup language Markdown

Wed, 18 Oct 2023 00:00:00 +0000

Markdown is a lightweight markup language for creating formatted text using a plain-text editor. John Gruber created Markdown in 2004 as a markup language that is easy to read in its source code form. Markdown is widely used for blogging and instant messaging, and also used elsewhere in online forums, collaborative software, documentation pages, and readme files.

The initial description of Markdown contained ambiguities and raised unanswered questions, causing implementations to both intentionally and accidentally diverge from the original version. This was addressed in 2014 when long-standing Markdown contributors released CommonMark, an unambiguous specification and test suite for Markdown.

Markdown syntax.

To create a heading, add number signs (#) in front of a word or phrase. The number of number signs you use should correspond to the heading level. For example, to create a heading level three (<h3>), use three number signs (e.g., ### My Header).
To create paragraphs, use a blank line to separate one or more lines of text.
To create a line break or new line (<br>), end a line with two or more spaces, and then type return.
To bold text, add two asterisks or underscores before and after a word or phrase. To bold the middle of a word for emphasis, add two asterisks without spaces around the letters.
To italicize text, add one asterisk or underscore before and after a word or phrase. To italicize the middle of a word for emphasis, add one asterisk without spaces around the letters.
To emphasize text with bold and italics at the same time, add three asterisks or underscores before and after a word or phrase. To bold and italicize the middle of a word for emphasis, add three asterisks without spaces around the letters.
To create a blockquote, add a > in front of a paragraph.
To create an ordered list, add line items with numbers followed by periods. The numbers don’t have to be in numerical order, but the list should start with the number one.
To create an unordered list, add dashes (-), asterisks (*), or plus signs (+) in front of line items. Indent one or more items to create a nested list.
To add an image, add an exclamation mark (!), followed by alt text in brackets, and the path or URL to the image asset in parentheses. You can optionally add a title in quotation marks after the path or URL.
In-text formulas are created similarly to LaTeX formulas.
To convert a Markdown-file to pdf or docx, you can use the following Makefile and use the “make all” command on the command line.

You can read more about this here and here.

Continuous Integration and Continuous Delivery (CI/CD)

Thu, 05 Oct 2023 00:00:00 +0000

Continuous Integration and Continuous Delivery (CI/CD) is a software development approach that aims to improve the speed, efficiency, and reliability of software delivery. This approach involves frequent code integration, automated testing, and continuous deployment of software changes to production. Before the adoption of CI/CD in the software development industry, the common approach was a traditional, waterfall model of software development. In this approach, developers worked in silos, with each stage of the software development life cycle completed in sequence. The process typically involved gathering requirements, designing the software, coding, testing, and deployment.

The disadvantages of this traditional approach include:

Slow Release Cycles
High Failure Rates
Limited Collaboration
High Cost
Limited Agility

CI/CD emerged as a solution to these disadvantages, by introducing a more agile and collaborative approach to software development. CI/CD enables teams to work together, integrating their code changes frequently, and automating the testing and deployment process.

Continuous Integration (CI)

CI is the process of merging all the Developer code changes to a single shared main branch as often as possible, frequently. Developers merge their code changes, many times a day to the remote Git Repository’s main branch. These code changes are then verified and validated by using automation to create builds and run tests on the created builds. So, the new code changes being pushed are built, integrated and tested in a few minutes, providing immediate feedback to the developer about the code status and any issues. Continuous Integration ensures that the application is not broken whenever new commits from all the developers are integrated into the Release branch of the Repository, as they are all tested well in advance.

Continuous Delivery (CD)

Continuous Delivery is the practice where the code changes are released frequently in shorter cycles to customers, quickly and reliably. In continuation with Automated Testing in CI, the application Release process is completely automated so that the code changes can be deployed incrementally at any point of time by just clicking a button (manual trigger). Generally, shorter release cycles are recommended. Depending on the size of the project, and business requirements, you can configure daily, weekly, fortnightly release schedules. The shorter the release cycle the easier it is to troubleshoot in case of any issue after deployment onto a Production environment.

Continuous Deployment (CD)

Continuous Delivery without a manual trigger is Continuous Deployment. In Continuous Deployment, every code change is directly released to customers without any manual intervention if it successfully passes all the stages of your CI/CD pipeline. So, if there are no failures in any pipeline tests, every code change is available to the customers immediately. This level of automation is made possible by a combination of several different tools and processes that work together to verify and push the code changes to production. Once the developer pushes the new code change, it is automatically built, integrated, tested, and directly deployed to the production environment.

The key benefits of CI/CD include:

Faster Release Cycles
Improved Quality
Increased Collaboration
Reduced Risk
Cost-Effective

In summary, CI/CD emerged as a solution to the limitations of the traditional, linear approach to software development. By introducing a more agile and collaborative approach to software development, CI/CD enables teams to work together, release software more frequently, and respond quickly to customer needs.

You can read more about this here and here.