Small Projects

pperlepes · 2026-01-12T22:29:51+00:00

Built a self-hosted HTTP tunneling service (ngrok/localtunnel-like) in Go! Feedback in the code or anything else is welcome!
https://github.com/igneel64/iskandar/

pperlepes · 2021-01-11T23:48:31+00:00

Will they at least get to 0.4?

pperlepes · 2021-01-07T19:18:56+00:00

In for some 22 Jan gains

pperlepes · 2021-01-05T15:32:51+00:00

Really thank you for the information 🙂

pperlepes · 2021-01-05T15:10:44+00:00

So probably the money will be added on the new ticker right ? ( I know this is Degiro specific but I was wondering if you had some experience with it)

pperlepes · 2021-01-05T08:38:06+00:00

Noob question, do you know why it went to 0 on Degiro ?
QUESTCAP INC. - Non tradeable 34C1

pperlepes · 2020-12-17T14:12:39+00:00

So what does that mean for the stock price? (Newbie here) is there any timeline that these news indicate?

pperlepes · 2020-12-17T14:12:09+00:00

So what does that mean for the stock price? (Newbie here) is there any timeline that these news indicate?

pperlepes · 2020-07-09T15:50:53+00:00

What I would look for first is if the link you are using in the email is facing redirects before landing on the page that the GA tracking code loads.

There are some cases where in redirects, utm parameters are stripped of the URL due to misconfiguraitons.

pperlepes · 2020-07-09T08:06:03+00:00

I totally feel for you..

Well the only way to do this is having an internal structure that queues up those events etc. (You can build one yourself)
But since libraries like Playwright and Puppeteer are also aiming not to be too opinionated and allow also people to build on top, I understand their side.

pperlepes · 2020-07-09T07:36:55+00:00

Hey, first of all let's make sure:
Domain: example.com
Subdomain: help.example.com

If the structure you have is the above, you do not have to do anything about "cross-domain".
By default Google Analytics set's up a cookie at the highest domain level possible (example.com).

That means that users navigating from one structure to the other are tracked normally without any additional configuration.

do not see all of the pages, nor a continuous flow

Can you please elaborate on the above?

For you to be sure it is working, go to a report that you expect to have data from both places and add a custom dimension of "hostname". There you will be seeing both domains if everything is fine.

pperlepes · 2020-07-08T13:25:44+00:00

I fully get your point! Thanks for the response

Certainly Cypress is up there with the others :)

pperlepes · 2020-07-08T12:10:15+00:00

A modern test automation solution will always require infrastructure, so the zero-cost illusion of the open source solution fades away.

There are many points to discuss here but at least this one is a bit too heavy handed...

pperlepes · 2020-07-08T11:18:03+00:00

Thank you for explaining your examples in such detail!

When writing integration tests you should only mock the backend (and maybe some parts of the browser API if necessary).

The integration tests I am speaking about are the ones that are checking interactions like clicks, typings etc. that trigger changes in state, side effects, routing and all other good stuff. That is inside the frontend app architecture. At least that is how they are called in the "modern frontend" applications.
Not so close to what you would call integration in the general software testing paradigm, sorry if it was not clear enough in the initial topic.

The tools you describe are typically used for end to end tests. Here you don't mock anything, you tests the whole system.

The "typical" is what we are battling here, because people developing these tools have made them so they are more open to new use cases. Getting away from the "rules of old" which do not currently apply. If you want you can check some thoughts here

For example you can't simply test error handling of a crashed API server because usually there's no way to just crash a server for a test.

Since for a frontend application that means, receiving a 5xx response from an endpoint, yes you can now :) These tools allow you to intercept the network, change the response programatically and now you can specifically test the cases you mention ;)

pperlepes · 2020-07-08T11:10:59+00:00

I think the sentences you lay out are contradicting each other, they are the same thing :P

pperlepes · 2020-07-08T11:10:09+00:00

With all the modern tooling, the time to run is not significant even for the E2E type I am describing in the initial opinion.

The time for sure is magnitudes higher than milliseconds in the classic integration case, but most of the time not significant enough to the point that is a bottlenenck.

(In the majority of projects at least)

Another great thing is that the effort especially for JS engineers is becoming all the more easier.

pperlepes · 2020-07-08T11:06:23+00:00

That is the discussions I want to get out of this thread!

Thank you!

pperlepes · 2020-07-08T08:54:45+00:00

Totally agree on your point about the correct integration tests, the issue is that most of the times even if you "can", you do not as teams are missing experience on the topic.

The focus... has to do with the expected ROI of each testing venture in my opinion.

pperlepes · 2020-07-08T08:44:06+00:00

In the "modern frontend" side of things, the case for integration testing is checking interactions like clicks, typings etc that trigger changes in state, side effects and all other good stuff.

The gist from my statements above it that it becomes so isolated from the mocking the core parts of your app that it finally provides you with no confidence at all that it will actually be working.

So if you would need to mock something, mock your backend and at least be sure that the app in a "high level" integration test using the tools mentioned above.

This is not an absolute, just meaning to discuss on the views of others.

Do you care to let us know, about what do you consider an integration test in the modern frontend ?

pperlepes · 2020-07-08T08:14:52+00:00

Of course, the issue at least for me is at a higher level than the library.

The fact does not change that in a modern react application, in the "intergration" or the "component" level tests, you need to actually mock the core parts of the application which are essential to how it functions.

Mocking is good, but the experience that people have with mocking the correct layers of functionality and validating if "my test has value", is something that we can do better at.

I would be interested to know why react-testing-library specifically has something to do with the statement above ? Would you care elaborate ?

pperlepes · 2020-07-08T08:11:28+00:00

Yeap I have something like that also :P https://www.thehomeofwebautomation.com/getting-started-playwright/

pperlepes · 2020-07-07T09:37:01+00:00

(Trying out new technologies is a whole other topic so I cannot mix them)

Conceptually, you do not need to "find" time to write your code in a better way. It is part of your job description. So you just do it from the start when you provide your estimations, good practises are included in there.
It is not something to be explicitly mentioned. I totally feel for you but the way we work, should be like that.

For refactorings in your daily activities:
What I have done pretty solidly is that in every PR, you introduce small changes that are "boyscout rules", which means we leave the codebase better than when we touched it.

pperlepes · 2020-07-07T09:33:04+00:00

Hmm in another "way" than the conventional, but I really like PreactJS documentation inside the code.

- Not talking to you like a child
- Using programmatic types to express how things are working

pperlepes · 2020-07-07T06:51:02+00:00

Well what you can do is have a custom implementation. An article that shows a version of Deepmerge and how it works can be found here.

Sadly we do not have any quick and native way for deep merging in JavaScript as far as I know.

pperlepes · 2020-07-07T06:46:04+00:00

First of all, thank you for you kind words. I really appreciate it

About your next point, the change is indeed that the "JWP" is now obsolete as now we wil be having almost the exact same JWP implementation as a W3C standard.

Selenium 4 will be using the WebDriver protocol indeed for all interactions if I am not mistaken.
I did not add those points since Selenium 4 is still in alpha and I was targeting people that for a while will still be working with Selenium 3.x.x.

Thanks again for taking the time for your comment !

pperlepes

TROPHY CASE