Tuesday, 5 December 2017

GRASP

General responsibility assignment software patterns (or principles), abbreviated GRASP, consist of guidelines for assigning responsibility to classes and objects in object-oriented design.

The different patterns and principles used in GRASP are: controller, creator, indirection, information expert, high cohesion, low coupling, polymorphism, protected variations, and pure fabrication. All these patterns answer some software problem, and these problems are common to almost every software development project. These techniques have not been invented to create new ways of working, but to better document and standardize old, tried-and-tested programming principles in object-oriented design.

Computer scientist Craig Larman states that "the critical design tool for software development is a mind well educated in design principles. It is not UML or any other technology."[1] Thus, GRASP are really a mental toolset, a learning aid to help in the design of object-oriented software.

The controller pattern assigns the responsibility of dealing with system events to a non-UI class that represents the overall system or a use case scenario. A controller object is a non-user interface object responsible for receiving or handling a system event.

A use case controller should be used to deal with all system events of a use case, and may be used for more than one use case (for instance, for use cases Create User and Delete User, one can have a single UserController, instead of two separate use case controllers).

It is defined as the first object beyond the UI layer that receives and coordinates ("controls") a system operation. The controller should delegate the work that needs to be done to other objects; it coordinates or controls the activity. It should not do much work itself. The GRASP Controller can be thought of as being a part of the application/service layer [2] (assuming that the application has made an explicit distinction between the application/service layer and the domain layer) in an object-oriented system with common layers in an information system logical architecture.

See also: Factory pattern

Creation of objects is one of the most common activities in an object-oriented system. Which class is responsible for creating objects is a fundamental property of the relationship between objects of particular classes.

In general, a class B should be responsible for creating instances of class A if one, or preferably more, of the following apply:

Instances of B contain or compositely aggregate instances of A

Instances of B record instances of A

Instances of B closely use instances of A

Instances of B have the initializing information for instances of A and pass it on creation.

Main article: Cohesion (computer science)

High cohesion is an evaluative pattern that attempts to keep objects appropriately focused, manageable and understandable. High cohesion is generally used in support of low coupling. High cohesion means that the responsibilities of a given element are strongly related and highly focused. Breaking programs into classes and subsystems is an example of activities that increase the cohesive properties of a system. Alternatively, low cohesion is a situation in which a given element has too many unrelated responsibilities. Elements with low cohesion often suffer from being hard to comprehend, hard to reuse, hard to maintain and averse to change.[3]

See also: Delegation pattern

The indirection pattern supports low coupling (and reuse potential) between two elements by assigning the responsibility of mediation between them to an intermediate object. An example of this is the introduction of a controller component for mediation between data (model) and its representation (view) in the model-view-controller pattern.

Information expert (also expert or the expert principle) is a principle used to determine where to delegate responsibilities. These responsibilities include methods, computed fields, and so on.

Using the principle of information expert, a general approach to assigning responsibilities is to look at a given responsibility, determine the information needed to fulfill it, and then determine where that information is stored.

Information expert will lead to placing the responsibility on the class with the most information required to fulfill it.[

Low coupling

Coupling is a measure of how strongly one element is connected to, has knowledge of, or relies on other elements. Low coupling is an evaluative pattern that dictates how to assign responsibilities to support:

lower dependency between the classes,

change in one class having lower impact on other classes,

higher reuse potential.

According to polymorphism principle, responsibility of defining the variation of behaviors based on type is assigned to the type for which this variation happens. This is achieved using polymorphic operations. The user of the type should use polymorphic operations instead of explicit branching based on type.

The protected variations pattern protects elements from the variations on other elements (objects, systems, subsystems) by wrapping the focus of instability with an interface and using polymorphism to create various implementations of this interface.

A pure fabrication is a class that does not represent a concept in the problem domain, specially made up to achieve low coupling, high cohesion, and the reuse potential thereof derived (when a solution presented by the information expert pattern does not). This kind of class is called a "service" in domain-driven design.

DRY and KISS Software Development Principles

In software engineering, don't repeat yourself (DRY) is a principle of software development aimed at reducing repetition of software patterns, replacing them with abstractions; and several copies of the same data, using data normalization to avoid redundancy.


The DRY principle is stated as "Every piece of knowledge must have a single, unambiguous, authoritative representation within a system". The principle has been formulated by Andy Hunt and Dave Thomas in their book The Pragmatic Programmer. They apply it quite broadly to include "database schemas, test plans, the build system, even documentation". When the DRY principle is applied successfully, a modification of any single element of a system does not require a change in other logically unrelated elements. Additionally, elements that are logically related all change predictably and uniformly, and are thus kept in sync.
DRY vs WET solutions


Violations of DRY are typically referred to as WET solutions, which is commonly taken to stand for either "write everything twice", "we enjoy typing" or "waste everyone's time". WET solutions are common in multi-tiered architectures where a developer may be tasked with, for example, adding a comment field on a form in a web application. The text string "comment" might be repeated in the label, the HTML tag, in a read function name, a private variable, database DDL, queries, and so on. A DRY approach eliminates that redundancy by leveraging frameworks that reduce or eliminate all those edit tasks excepting the most important one, leaving the extensibility of adding new knowledge variables in one place.


KISS is an acronym for "Keep it simple, stupid" as a design principle noted by the U.S. Navy in 1960. The KISS principle states that most systems work best if they are kept simple rather than made complicated; therefore simplicity should be a key goal in design and unnecessary complexity should be avoided. Variations on the phrase include "Keep it Simple, Silly", "keep it short and simple", "keep it simple and straightforward" and "keep it small and simple".

Javascript Crash Course




1. Learn Javascript by 24 tricks:

1.1. Immediately-Invoked Function Expression (IIFE)
https://www.google.pl/search?q=js+iife&rlz=1C1GGRV_plPL752PL752&oq=js+iie&aqs=chrome.2.69i57j0l5.4121j0j7&sourceid=chrome&ie=UTF-8

1.2. Clousures
Domknięcia to funkcje których funkcje wewnętrzne odwołują się do niezależnych (wolnych) zmiennych. Innymi słowy, funkcje zdeklarowane wewnątrz domknięcia 'pamiętają' środowisko w którym zostały utworzone.
Readmore: https://developer.mozilla.org/pl/docs/Web/JavaScript/Domkniecia

2. SOLID principles in JS



3. GRASP principles in JS








UI / browser javascript
4. Projects i am proud of and why




5. Technologies in my toolbox
Webpack

https://medium.com/eventmobi/why-we-switched-to-webpack-69b7396f3ec5



6. Debugging and  profiling nodejs apps







SOLID principles

Single responsibility principle

a class should have only a single responsibility (i.e. changes to only one part of the software's specification should be able to affect the specification of the class).

Open/closed principle

“software entities … should be open for extension, but closed for modification.”

Liskov substitution principle

“objects in a program should be replaceable with instances of their subtypes without altering the correctness of that program.” See also design by contract.

Interface segregation principle

“many client-specific interfaces are better than one general-purpose interface.”

Dependency inversion principle

one should “depend upon abstractions, [not] concretions.”

Zasada odwracania zależności składa się z dwóch następujących części:
  1. Moduły wysokopoziomowe nie powinny zależeć od modułów niskopoziomowych. Obie grupy modułów powinny zależeć od abstrakcji.
  2. Abstrakcje nie powinny zależeć od szczegółowych rozwiązań. To szczegółowe rozwiązania powinny zależeć od abstrakcji.
Jeśli chodzi o zależność od abstrakcji, można to zamknąć w jednej prostej formule: pisany przez nas kod nie powinien być uzależniony od konkretnej klasy, zależności takie powinny kończyć się na klasach abstrakcyjnych bądź interfejsach. Zasadę zależności od abstrakcji (ang. depend on abstractions) można również streścić w trzech prostych punktach:
  • Żadna zmienna nie powinna zawierać referencji do konkretnej klasy.
  • Żadna klasa nie powinna dziedziczyć po konkretnej klasie.
  • Żadna metoda nie powinna przykrywać metody zaimplementowanej w którejkolwiek z klas bazowych.
  • Podstawowymi zaletami zasady odwracania zależności jest to, że właściwe jej stosowanie jest kluczowe, jeśli chcemy tworzyć frameworki wielokrotnego użytku. Ma ona również duży wpływ na odporność kodu źródłowego na przyszłe zmiany, ponieważ zgodnie z tą zasadą abstrakcje, a także szczegółowe mechanizmy są od siebie odizolowane, co z kolei wpływa na to, że tworzony kod jest dużo prostszy w konserwacji.
Code examples of SOLID principles for JavaScript
https://gist.github.com/Crizstian/ba39c6fdbb30a40c738e3c07ea83b5c1



Wednesday, 26 December 2012

Audyt SEO


Audyt seo jest niezbędnym elementem procesu projektowania i pozycjonowania strony internetowej. W trakcie audytu szczegółowo analizujemy 5 głównych obszarów:

  1. Accessibility
  2. Indexability
  3. On-Page Ranking Factors
  4. Off-Page Ranking Factors
  5. Competitive Analysis

Kompletny audyt zawiera analizę ponad 300 czynników, które wpływają na pozycję Twojej strony w rankingu wyszukiwarek. Do jego sporządzenia używamy kilkunastu profesjonalnych narzędzi do analizy seo. Bądź bardziej widoczny, zmiejsz koszty – nie zwlekaj, zapytaj o szczegóły.


1. Accessibility

Accessibility to miara dostępności witryny i informacji w niej zawartych dla odwiedzającego.

  • Site Architecture
  • Site Navigation
  • Site Performance
  • Robots.txt
  • Robots Meta Tags
  • HTTP Status Codes
  • XML Sitemap

2. Indexability

Indexability to miara zdolności witryny do bycia pobraną i zindeksowaną przez roboty wyszukiwarek.

  • Hosting
  • Server uptime
  • Site: Command
  • Index Sanity Checks
  • Page Searches
  • Brand Searches
  • Search Engine Penalties

3. On-Page Ranking Factors

Wewnętrzne czynniki wpływające na pozycję witryny w rankingu wyszukiwarek.

  • URLs
  • Content
  • Structure / Internal linking
  • Titles
  • Images / Media
  • Outlinks
  • HTML Code

4. Off-Page Ranking Factors

Zewnętrzne czynniki wpływające na pozycję witryny w rankingu wyszukiwarek.

  • Authority
  • Popularity
  • Backlink profile
  • Social Engagement

5. Competitive Analysis

Im więcej wiesz o konkurencji, tym łatwiej zindetyfikujesz swoje słabe punkty.

  • Keywords
  • Overall Page Quality
  • Backlink profile


Friday, 23 November 2012

Projektowanie stron, pozycjonowanie - Katowice, Sosnowiec, Będzin

Strona kierowana jest do tych, którzy rozumieją wartość marketingu internetowego i wiedzą jak mierzyć tę wartość. Do tych, którzy zastanawiają się jak działa ta technologia, jaką strategię wybrać dla firmy, organizacji, strony internetowej. Nie ma tu gotowych rozwiązań, jest to miejsce gdzie możesz zapytać kogoś, kto ma doświadczenie i od wielu lat robi dokładnie to, co Ty zamierzasz robić.

Zapraszam na moją stronę: Projektowanie stron, pozycjonowanie - Katowice, Sosnowiec, Będzin

Sunday, 18 November 2012

Miłosz Szarek @ Picasa


Picasa is an image organizer and image viewer for organizing and editing digital photos, plus an integrated photo-sharing website, originally created by a company named Lifescape (which at that time may have resided at Idealab) in 2002 and owned by Google since 2004. “Picasa” is a blend of the name of Spanish painter Pablo Picasso, the phrase mi casa (Spanish for “my house”) and “pic” for pictures (personalized art). In July 2004, Google acquired Picasa from its original author and began offering it as freeware.
For organizing photos, Picasa has file importing and tracking features, as well as tags, facial recognition, and collections for further sorting. It also offers several basic photo editing functions, including color enhancement, red eye reduction, and cropping. Other features include slide shows, printing, and image timelines. Images can also be prepared for external use, such as for e-mailing or printing, by reducing file size and setting up page layouts. There is also integration with online photo printing services. Other simple editing features include adding text to the image. Picasa supports Google’s WebP image format as well as the JPG format and most Raw image format (RAW files). A user can view and edit RAW files and save the finished edit (as JPG, or other forms) without any changes to the original RAW file.