CSS grid

- This post was highly inspired by this article.
First, we used tables, then floats, positioning and inline-block, but all of these methods were essentially hacks and left out a lot of important functionality (vertical centering, for instance). Flexbox helped out, but it's intended for simpler one-dimensional layouts, not complex two-dimensional ones (Flexbox and Grid actually work very well together). Grid is the very first CSS module created specifically to solve the layout problems we've all been hacking our way around for as long as we've been making websites.
To get started you have to define a container element as a grid with display: grid, set the column and row sizes with grid-template-columns and grid-template-rows, and then place its child elements into the grid with grid-column and grid-row.
Terminology:
Grid Container: The element on which display: grid is applied.
Grid Item: The children (i.e. direct descendants) of the grid container.
Grid Line: The dividing lines that make up the structure of the grid.
Grid Track: The space between two adjacent grid lines.
Grid Cell: The space between two adjacent row and two adjacent column grid lines.
Grid Area: The total space surrounded by four grid lines.

Properties for the Grid Container:

• display: Defines the element as a grid container and establishes a new grid formatting context for its contents.
• values: grid, inline-grid
• grid-template-columns, grid-template-rows: Defines the columns and rows of the grid with a space-separated list of values.
• values: <track-size> - can be a length, a percentage, or a fraction of the free space in the grid (using the fr unit), <line-name> - an arbitrary name of your choosing.
• The fr unit allows you to set the size of a track as a fraction of the free space of the grid container. For example, this will set each item to one third the width of the grid container:
• grid-template-areas: Defines a grid template by referencing the names of the grid areas which are specified with the grid-area property. 
• values: <grid-area-name> - the name of a grid area specified with grid-area
• grid-template: A shorthand for setting grid-template-rows, grid-template-columns, and grid-template-areas in a single declaration.
• grid-column-gap, grid-row-gap: Specifies the size of the grid lines. You can think of it like setting the width of the gutters between the columns/rows. Shorthand: grid-gap
• justify-items: Aligns grid items along the inline (row) axis (as opposed to align-items which aligns along the block (column) axis). This value applies to all grid items inside the container.
• align-items: Aligns grid items along the block (column) axis (as opposed to justify-items which aligns along the inline (row) axis). This value applies to all grid items inside the container.
• place-items: sets both the align-items and justify-items properties in a single declaration.
• justify-content: This property aligns the grid along the inline (row) axis (as opposed to align-content which aligns the grid along the block (column) axis).
• values: start, end, center, stretch, space-around, space-between, space-evenly
• align-content: This property aligns the grid along the block (column) axis (as opposed to justify-content which aligns the grid along the inline (row) axis).
• place-content: place-content sets both the align-content and justify-content properties in a single declaration.
• grid-auto-columns, grid-auto-rows: Specifies the size of any auto-generated grid tracks (aka implicit grid tracks).
• grid-auto-flow: If you have grid items that you don't explicitly place on the grid, the auto-placement algorithm kicks in to automatically place the items. This property controls how the auto-placement algorithm works.
• grid: A shorthand for setting all of the following properties in a single declaration: grid-template-rows, grid-template-columns, grid-template-areas, grid-auto-rows, grid-auto-columns, and grid-auto-flow

Properties for the Grid Items:

• grid-column-start, grid-column-end, grid-row-start, grid-row-end: Determines a grid item's location within the grid by referring to specific grid lines. grid-column-start/grid-row-start is the line where the item begins, and grid-column-end/grid-row-end is the line where the item ends.
• grid-column, grid-row: Shorthand for grid-column-start + grid-column-end, and grid-row-start + grid-row-end, respectively.
• grid-area: Gives an item a name so that it can be referenced by a template created with the grid-template-areas property. Alternatively, this property can be used as an even shorter shorthand for grid-row-start + grid-column-start + grid-row-end + grid-column-end.
• justify-self: Aligns a grid item inside a cell along the inline (row) axis (as opposed to align-self which aligns along the block (column) axis). This value applies to a grid item inside a single cell.
• align-self: Aligns a grid item inside a cell along the block (column) axis (as opposed to justify-self which aligns along the inline (row) axis). This value applies to the content inside a single grid item.

My favorite trick in Angular / RxJS

I really love Andular and TypeScript in general, and love to work with Observables.
Observables, however, can be very hard to get done correctly, which obviously needs a lot of debugging. But how?
There are plenty of options for that, for example subscribing to an observable. This might be ok, but is a bit tedious, and doesn't tell you, if there are actually other objects subscribing to it (Subscribers). And, in my experience, is usually one of the most frequent problem by using Observables.

BUT! There is a neat way of checking if your Observable actually has subscribers or not.
Let me tell you about an RxJS operator: tap. I quote from learnrxjs.io:

Transparently perform actions or side-effects, such as logging.

What that means is that this operator does not mutate the values emitted from the Observable, this is just having a sneak peak at the values. This is very good for you to log something there and check if the Observable works.

In summary: as you could see from these 2 examples, you can debug Observables in an Angular project with many ways, but my experience told me to use the tap(console.log) "trick", because then I'm not explicitly subscribing to the Observable, rather just listening and peaking if there is someone who actually would like to subscribe for changes. Cheers!

NgRX debugging presentation

I held a tech talk at my current company, where I talked about Angular 7, Redux and NgRX.
Here are the slides, enjoy!
https://nagyadam2092.github.io/work/ngrx-presentation/

Detecting Image().src = 'URL' changes

Thesedays I am working a lot with image beacons, which are basically prefetched image pixels sent from a page for tracking reasons.
It's very hard to detect when these pixels are trying to be requested, most of the testing environments are going to listen to a mock server and see if an image request was made or not.
However, with the new Reflect API you are able to listen to simple assignments like new Image().src = 'URL'.
Obviously this won't work in browsers which don't support Symbol or Proxy, but is a good way to test image beacons in fairly modern browsers.
This approach was basically stolen from this blog post: https://www.phpied.com/intercepting-new-image-src-requests/
Have fun playing around with this fiddle:

See the Pen Image beacon testing by Adam Nagy (@nagyadam2092) on CodePen.

The early days of my web development carreer

Here is a bit different article about how software engineering in general got into my life when I was a teenager.
I think my first connection with computer science, or more specifically web development, was when I was about 10 years old (or even younger?), my father was working as a JAVA developer, and one of his colleagues in Switzerland had a homepage which was extremely simple: basically there was the name of his, some weather information about his hometown (as far as I remember) - AND (that's the most important part) a real time webcam!
"How was that real time?", you may ask, and is a very valid question.
Imagine we are in 1998, where weird browsers were popping up from every corner (without any standards, yikes!). So how could one implement a real-time webcam on a webpage?
The trick was that there was an image (which you could see as a real-time camera), which was refreshed every 10 or 20 seconds (so basically changing it's URL from JavaScript /or maybe it wasn't JS? not sure../).
That was so mindblowing for me, I couldn't really imagine I could build something like that even if I spent a whole lifetime learning it.
After that my next meeting with Computer Science was Comenius Logo. To be honest, I believe I was a very bad "programmer" back then since I thought "What is the point of this? Moving a turtle around the screen with an overly verbose way? That's just simply pointless.".

So I was not super motivated about Comenius Logo. I only remember the games which we were playing after school on Pentium 1-s (Outlaws multiplayer on LAN ftw!).

After that I basically tried myself as a "homepage developer" without knowing that I was doing any programming - since I only wrote HTML code without any coding involved. One could say it WAS programming, but I highly doubt that.
That was the time when I met MS Frontpage 2003.

So I built a homepage basically to share gaming photos about Warcraft 3 and GTA: Vice City. This homepage had a header (!), a footer (!) and also a sidebar (!!).
It was one of the best experiences developing it and uploading it via FTP to a free hosting service, which had a never disappearing ad banner at the top of every page. It was not that annoying by that time since I was like "WHOA! I have a webpage! Who cares about freaking ads?".
So yeah, that was it, after that I started to develop other very small webpages, and started to explore the world of the interwebz.

Testing AWS Lambda function which uses S3 using Mocha and Sinon

I've been seeking through the interwebz to find a good tutorial on testing an AWS lambda function which uses it's S3 API, so here we go, this is my take on it.
The key idea behind it is to have a 4th default argument which is going to be a Sinon spy at the test, just to mock S3's behaviour. Here we go, there is the solution I came up:

Spring framework

Although I'm working with Spring on a daily basis, sometimes it's good to revisit the basics of a framework / concept. So I did, and here are my notes. Cheers!

Configuring the Application Context

Inversion of Control

AKA Dependency Injection
Objects are injected at runtime.

Profiles

You can set profiles like develop or production to be able to branch the code.
@Profile(“develop”)     --- this anniotation makes sure to run that method.

Bean Scopes

• singleton: Scopes a single bean definition to a single object instance per Spring IoC container.
• prototype: Scopes a single bean definition to any number of object instances.
• request: Scopes a single bean definition to the lifecycle of a single HTTP request; that is each and every HTTP request will have its own instance of a bean created off the back of a single bean definition. Only valid in the context of a web-aware Spring ApplicationContext.
• session: Scopes a single bean definition to the lifecycle of a HTTP Session. Only valid in the context of a web-aware Spring ApplicationContext.
• global session: Scopes a single bean definition to the lifecycle of a global HTTP Session. Typically only valid when used in a portlet context. Only valid in the context of a web-aware Spring ApplicationContext.

e.g.: @Scope(“singleton”)

Proxies

Since Spring 4.0 every class which is loaded into the Bean Factory gets at least one Proxy.

Annotation based configuration

@Component scan

This indicates that a class should be loaded to the bean factory.
Dependency injection is achieved through @Autowired.

Autowiring

Field level: private attributes can be autowired, but not a good practice.
Setter Injection: inject at the setter method.
Constructor Injection: good practice,  inject at the constructor. Class become immutable.

…
InventoryService inventoryService;

@Autowired
public OrderServiceImpl(InventoryService inventoryService) {
this.inventoryService = inventoryService;
}

Lifecycle methods

@PostConstruct: method being run after constructor.
@PreDestroy: method being run before destructor is called.

Bean lifecycle

Initialization phase:

• Begins with creation of ApplicationContext
• BeanFactory initialization phase
• Bean initialization and instantiation

1. Bean definitions loaded: from Java configuration, Bean configuration, Component scanning and aut configuration
2. Post-process bean definitions: BeanFactory is loaded with references 
3. Instantiate Bean: Bean pointer is still referenced in Bean Factory, Objects have been constructed, BUT not available for use yet!
4. Setters: beans are fully initialized; all initial dependencies are injected - beans still not ready for use
5. Bean post-processor (pre- and post-init): almost the same as Initializer
6. Initializer: @PostConstruct methods are called here; after the step beans are instantiated and initialized, dependencies have been injects, BEANS READY TO USE

Aspect Oriented Programming (AOP)

Aspects: reusable blocks of code that that are injected into your application during runtime.
Applications:

• Logging
• Transactions
• Caching
• Security

Cross-cutting concerns: In aspect-oriented software development, cross-cutting concerns are aspects of a program that affect other concerns. These concerns often cannot be cleanly decomposed from the rest of the system in both the design and implementation, and can result in either scattering (code duplication), tangling (significant dependencies between systems), or both. - So there are code parts which are concerned at other places which would cose a lot of code duplication.

In Spring AspectJ is handling the aspecting.

Parts of a Spring Aspect:

• Aspect: A modularization of a concern that cuts across multiple objects. Transaction management is a good example of a crosscutting concern in J2EE applications. In Spring AOP, aspects are implemented using regular classes (the schema-based approach) or regular classes annotated with the @Aspect annotation (@AspectJ style).
• Join point: A point during the execution of a program, such as the execution of a method or the handling of an exception. In Spring AOP, a join point always represents a method execution. Join point information is available in advice bodies by declaring a parameter of type org.aspectj.lang.JoinPoint.
• Advice: Action taken by an aspect at a particular join point. Different types of advice include "around," "before" and "after" advice. Advice types are discussed below. Many AOP frameworks, including Spring, model an advice as an interceptor, maintaining a chain of interceptors "around" the join point.
• Pointcut: A predicate that matches join points. Advice is associated with a pointcut expression and runs at any join point matched by the pointcut (for example, the execution of a method with a certain name). The concept of join points as matched by pointcut expressions is central to AOP: Spring uses the AspectJ pointcut language by default.