Auteur/autrice : istudormarius

About .Net Standard

The .NET ecosystem is available as a stack for any kind of developer (mobile, desktop, cloud, Windows or non-Windows). Every platform has a different base class library so if you want to encapsulate parts of your application (or create a new library ) that will run on all platforms you will need implementations for each platform. So, the solution was to unify all these base class libraries into one base class library called .NET Standard. This way, a developer can master only one base class library, the code reuse targets a big surface area and the .NET Standard can grow faster without updating any platforms.

.NET Standard is a specification and in the same time a type of class library with a set of APIs that the current and future platforms have to implement.

.NET Standard will replace Portable class libraries.

Higher versions of .Net Standard will incorporate all APIs from previous versions.

Specific platforms of .NET implements specific version of .NET Standard.

How do you choose what version of .NET Standard to target?

  • the higher the number of the version of .NET Standard is the more APIs you have available
  • the lower the number of the version of .NET Standard is the more platforms you can run on (the more .NET platforms implemented the standard)

Read more about .NET Standard: https://github.com/dotnet/standard

The catalog of APIs – https://apisof.net/

 

About OWIN

Web is evolving fast and web development needs to keep up with it.
One solution is to have an abstraction between the web appplication and the web server.
OWIN (Open Web Server Interface for .NET) – standard interface between .NET web servers and web applications. It decouples server and application. There is no code for OWIN, there are only just specicifications for the real implementation of a custom web server.

OWIN defines a standard interface for web servers and .NET client applications and Katana and Nowin are some implementations.
OWIN runs on the server, answers to HTTP requests, and forwards them to its middleware.

IIS – a super-tested web server but its biggest limitation is that it is related to the OS.

OWIN is not related to the OS, you can build your custom host and add whatever you want in the HTTP request processing pipeline.
The OWIN specs define four layers:
Host: where the server is launched and startup
Server: This is the actual HTTP server, the one binding to the network socket to listen to
requests and sending them to the pipeline of OWIN middleware components.
Middleware: components that stand between the server and the final
application code, and handle the requests sent through the OWIN pipeline(a logger or a full web frameworks like
Web API or SignalR). As far as the server is concerned, a middleware component is
anything that implements the application delegate.
Application: the specific application code, possibly built on top of a web
framework.

SOLID Principles

Single Responsibility Principle – the methods and classes should focus on doing one thing and doing it well

Open Closed Principle – extend the classes instead of modifying them – Open for extension, closed for modification. Imagine you want to add a basement to your house. You don’t want to change the code that is already in production.

Liskvov Substitution Principle – Derived classes can stand in before base classes – Code against an interface.

Interface Segregation Principle – Make fined grained interfaces client specific –

Dependency Inversion – Depend on abstractions, not concrete implementations

 

HTML and Javascript notes

Semantic Markup – text data that is annotated with a special language to offer more sense or meaning to the text.

SGML (Standard Generalized Markup Language) permitted to researchers to format their documents

HTML – an extension of SGML.

Tim Berners-Lee published aWorldWideWeb – a system of hypertext documents viewed by software named browsers in a client-server architecture.

World Wide Web Consortium (W3C)

Web browser – a gateway to the web-application (retrieve and present the content,allow navigating through different web pages)

 

Istoria, joc fara reguli

Lucian Boia,  Un joc fara reguli.

Imprevizibilitatea istoriei, principala caracteristica.

Istoria nu se repeta, se pot repeta sau pot fi asemanatoare anumite « episoade », dar ansamblul e mereu diferit.

Oamenii fac Istoria, dar nu o pot stapani.

Excercitii de interpretare: al doilea razboi fara Hitler, unirea Principatelor ca un proces petrecut la limita privita ca o oportunitate pentru putina vreme, crearea Romaniei (conditiile ideale pentru Romania la sfarsitul lui 1918), geneza Occidentului si ce s-ar fi intamplat daca europenii nu ar fi avut setea de cunoastere si de dominatie?

 

Things any programmer should know #4

  • A good bug report must express three things:
    • how to reproduce the bug
    • what should have happened, in your opinion
    • what actually happened, with as much information as you can record
  • You can improve code by removing it. You Aren’t Gonna Need It.
  • Remove all you warnings or deal right away with a warning when it appears. You need to get rid of the noise.
  • Know your IDE but try working with command-line build tools, they can help look under the hood and understand what is going on.

 

Things any programmer should know #3

  • Understand as much as you can the project you work on
  • A common web-based development architecture:
    • local development and unit testing on the developer’s machine
    • development server where manual or automated integration testing is done
    • staging server where the QA team and the users do acceptance tests
    • production server
  • If something is broken, it should not be fixed on production.
  • There is no guru. There should be an expert willing to develop other experts.

Things any programmer should know #2

  • Don’t ignore an error!It will raise problems in the future.
  • Write comments only when the code doesn’t or can’t say something.
  • Technical exceptions will be handled by the application framework while the business domain exceptions by the client code.
  • Deploy often.
  • Challenge yourself by doing what you are not good at (deliberate practice).

Things any programmer should know #1

  1. Create shared library only when you know the context. Sometimes, while decreasing the number of line of code in the system the number of dependencies is increased.
  2. Care for the team’s code. Make it a little bit better than when you checked it out.
  3. Debug your own code before rushing to blame others.
  4. Choose the right mix of tools:
    1. avoid architectural mistmatch (some tools are good only in some specific contexts)
    2. avoid using too many
    3. should be easy to configure
    4. licensing terms matter
    5. start by using only the tools that are absolutely necessary