When will Google understand what an ecosystem means ?

Love it or hate it. What makes Apple devices homely is the ability to build a banded and consolidated associative user space that feels the same anytime on any platform. Crafting an ecosystem might be a daunting task , and requires adaptive and perfective rework through a long period. But it pays of , just like apples utility app suite does today. It was a journey to get it right.

Now we have Google , a company that is confused most of the time , releasing new apps everytime they have new feature in mind. According to me , Google did a phenomenal job in building hangouts and Allo , hangouts was a huge step forward from gChat , and Allo was way ahead of its time for a fun and innovative IM app. But what's the need for 2 different apps ? One has video calling , text messaging , group sharing , everything the Allo had.

Then all of a sudden you get Google Duo " The best ever video calling app " Why wasn't this integrated with hangouts and marketed the same way ?

Trial and error is one thing , this seems a lot like the lack of effort in architecting coaction and a well designed internetworking application framework. A lot of unnecessary choices have led to the shutting down of majority of their apps. Allo and hangouts included , but all this would have been unnecessary if the goal was to always build upon iteratively.

While I believe Allo was marketed as a cross platform chat application unlike hangouts , an integration plan could have always circumvented this issue.

I have to talk about another one of Google's failed efforts in recognition of potential , the hello app , but this rant has gone a bit too far already. So I'll post 6 hours later 😅

Well I'll always have the hope to see Google integrate the best of their ideas in a more relaxed and realised structure than what exists today. :)

Hashedram's compilations #1
List of most annoying website designs.

1) Pages with AUTO PLAYING VIDEOS.

Yes I'm looking at you Netflix. Along with every news website known to man. I'm looking to read a fucking article, so why would you even waste your money and bandwidth trying to shove a video of some shit I don't care about in my face, and make it follow me as I scroll down like a fucking insecure puppy. Also, fuck you Instagram.

2) Pages that redirect once immediately after you visit them, thereby fucking with the browser history and the BACK BUTTON just leads back to the same fucking site.

I mean, just why. Did you think I would just go "Hey the back button doesn't work so let's stay on the site and read their awesome content"?

3) Sites showing things in a SLIDESHOW, when it actually should be in a list.

Slideshows are for progressive stories or for showing lists where you don't care about what's in them. Top 10 foods that reduce weight. Slideshow 1/15. Fuck you.

4) LOOKS LIKE YOU'RE USING AN AD BLOCKER

Yes. Yes I am. No I will not turn it off for you, you narcissistic snowflake fuck. And don't even try to guilt shame me into turning it off, because I know you're just going to bombard me with videos of sexy singles in the area if I do.

5) Pages where I see the first 3 lines of an article and have to SUBSCRIBE to see more.

Yes. Brilliant fucking idea. A user wants to see what your site has to offer, so within the first three seconds, don't show him exactly that.

6) Looking up an article and having to read through the entire motivational life story of the author.

I just want to know how to boil eggs, not read about your journey across Africa learning how to make difference recepies using boiled rhino dung.

7) CLICK BAIT.

Title: School boy designs blockchain machine learning game engine

Actual Content: Tic tac toe program made using linked lists

My dad used to be a Marketing Manager. He used to make a lot of presentations et al for his meetings. We got our first computer in our house when I was around 7 years old. It was first Windows 95, but I wasn't fortunate enough to even touch the machine. My dad was very protective about the machine. He himself would not use it unless he had to complete some work overnight. For me, it was an absolute wonder as to how and what that thing in the bedroom sitting on the desk next to my parents bedside was. I used to hide and peek around the door sill when my dad was working on it. He became a bit more lenient with the Windows 98 and let me and my sibling play DOS games under his supervision for a limited time.

Over time, I managed to look over his shoulder for the passwords - both BIOS and OS user passwords and started logging in myself. By now, my dad would let me sit on the bed near him when I looked curiously as he worked. Then I had to figure how to connect to the internet and surf the web. And there folks is how my journey with computers began.

The amount of much political correctness in the dev community just pisses me off sometimes.

I've watched "Use the right tool / language for the job" has become *THE* excuse for shitty tools and languages. 

Case in point -- JavaScript. If you want to make a website that interacts with the end user, the right tool is JavaScript. But that's because IT'S THE ONLY TOOL. Does that make it a *good* tool?

HELL NO.

/midranttimeout

Brendan Eich, I forgive you. You had 10 days and a corporation on your case.

That's not saying JavaScript doesn't have some good things in it. It does. But "Javascript the good parts" is a fucking thin book.

Sure, some amazing things have been written in JavaScript. Great communities have coalesced around this cancer.

BUT THATS IN SPITE OF JAVASCRIPT, NOT BECAUSE OF IT. AS A LANGAUGE IT'S STILL A STEAMING PILE OF DOGSHIT.

A master can draw great art with a shitty piece of charcoal. That doesn't make charcoal THE BEST DRAWING TOOL EVARRR. It's just a testament to the master's craft.

If you started your programming journey with JavaScript, do expand your horizons.

Break free from Stockholm's syndrome.

Discard your cognitive dissonance.

See JavaScript for what it is -- a shitty language everyone was forced to use. 

PS: Don't even get me started on Java ...

Hello everyone,
I'm new here. [OK. Let's skip this]
I want to know where to begin on my journey on learning how to create a program that predicts what a user will say next by storing already said things and by making specific characteristics for the users.

I know that I will need to train it with some data first lol.
But how will it do the prediction. I just need this part of understanding.

I'm sorry for my bad English btw.

A bit different than wk93, but still connected and a fun story.

Back in high school when it began to digitalize everything, so began our teachers journey with technology. We, as IT class were into these things, but as far as I can say, others in the school including both teachers and students were like cave mans when it came to IT.

Most of them kept the different wifi networks password on the windows desktop, in a file 'wifipassword.txt'. When we were on robotics seminar, we had to use a teacher's laptop. The wifi network was incredibly fast and powerful,, yet so poorly configured that even the configuration page user/pass was the default admin/admin, because the IT admin wasn't the most skilled one.

We got the idea to sell the password of the wifi network to other students. Not much, for about 1 dollar a week. The customer came to us, we took the phone, took note of the MAC address, entered the password, and if the guy were to stop paying every week, we just blacklisted that MAC on the next robotics course.

Went well for months, until a new sysadmin came and immediately found it out, we were almost fired from the school, but my principal realized how awesome this idea was. You may say that we were assholes, and partially that is true, I'd rather say we made use of our knowledge.

Been a Debian and Ubuntu user since the age of fifteen (21 now). Let's start a new journey! Installing Fedora as we speak 😀

Deleted accounts could have a skeleton/corpse as the picture.

Adding "no offense" in the tags just to be a bit polite.

VIM! ViM! vim! Vi Improved! Emacs (Wait ignore that one). What’s this mysterious VIM? Some believe mastering this beast will provide them with untold mastery over the forces of command line editing. Others would just like to know, how you exit the bloody thing. But in essence VIM is essentially a command line text editor at heart and it’s learning curve is so high it’s a circle.

There’s a lot of posts on the inter-webs detailing how to use that cruel mistress that is VIM. But rather then focus on how to be super productive in VIM (because honestly I’ve still not got a clue). This focus on my personal journey, my numerous attempts to use VIM in my day to day work. To eventually being able to call myself a novice.

My VIM journey started in 2010 around the same time I was transiting some of my hobby projects from SVN to GIT. It was around that time, that I attempted to run “git commit” in order to commit some files into one of my repositories.

Notice I didn’t specify the “-m” flag to provide a message. So what happened next. A wild command line editor opened in order for me to specify my message, foolish me assumed this command editor was just like similar editors such as Nano. So much CTRL + C’ing CTRL + Z’ing, CTRL + X’ing and a good measure of Google, I was finally able to exit the thing. Yeah…exit it. At this moment the measure of the complexity of this thing should be kicking in already, but it’s unfair to judge it based on today’s standards of user friendly-ness. It was born in a much simpler time. Before even the mouse graced the realms of the personal computing world.

But anyhow I’ll cut to the chase, for all of you who skipped most of the post to get to this point, it’s “:q!”. That’s the keyboard command to quit…well kinda this will quit the program. But…You know what just go here: The Manual. In-fact that’s probably not going to help either, I recommend reading on :p

My curiosity was peaked. So I went off in search of a way to understand this: VIM thing. It seemed to be pretty awesome, looking at some video’s on YouTube, I could do pretty much what Sublime text could but from the terminal. Imagine ssh’ing into a server and being able to make code edits, with full autocomplete et al. That was the dream, the practice…was something different. So I decided to make the commitment and use VIM for editing one of my existing projects.

So fired the program up and watched the world burn behind me. Ahhh…why can’t I type anything, no matter what I typed nothing seemed to appear on screen. Surely I must be missing something right? Right! After firing up the old Google machine, again it would appear there is this concept known as modes. When VIm starts up it defaults to a mode called “Normal” mode, hitting keys in this mode executes commands. But “Insert” entered by hitting the “i” key allows one to insert text.

Finally I thought I think I understand how this VIM thing works, I can just use “insert” mode to insert text and the arrow keys to move around. Then when I want to execute a command, I just press “Esc” and the command such as the one for saving the file. So there I was happily editing my code using “Insert” mode and the arrow keys, but little did I know that my happiness would be short lived, the arrow keys were soon to be a thorn in my VIM journey.

Join me for part two of this rant in which we learn the untold truth about arrow keys, touch typing and vimrc created from scratch. Until next time..

:q!

I've been working on the ecommerce website from hell for over a year now. I should have heard the alarm bells when the studio who were running the project took a month to pay my deposit but still expected me to start working, but I explained that I wouldn't start without some form of security and they were cool with it, so I carried on.

It started off as a simple build with simple products, no product variations etc and a few links on the designs which appeared to lead to external links, and checkout and cart pages were nowhere to be seen. It wasn't a big money job so I just build them in as plain and straightforward as I could, in line with how the rest of the site looked. They then changed their mind about how they wanted these to look, and added loads of functionality to the site throughout the build, so by the end of the line, the scope of work had completely changed. I also had loads of disagreements in terms of design and useability, as their designs straight-up weren't going to function otherwise, plus every round of changes meant that I had to prolong the job further and fit it around work for other clients.

Fastforward a few more months and I get sent a really angry email with some of the client's complaints, including one that raised an issue with the user journey, and the finger of blame was pointed at me. The user journey had been a part of the designs from the start, and this was never raised as an issue for A WHOLE YEAR. They then said that it had to go live on Monday (three days after they sent email with these huge new structural changes). I told them I could no longer work on the project but was happy to waive the rest of my fee (3/4 of the total fee, when I had essentially completed the site, minus 2 minor bugs), so they could find another developer in the limited time they had. At first they refused to hire another developer, claiming that it would be too expensive, which made no sense, as for a few minor fixes and out of scope additions he could get paid a wage that would have otherwise paid for the majority of the work I had done on the site. I stood my ground and finally they found someone, so I sent over all of the files and database to their new developer and asked him to give me a heads up when I could remove the staging site from my server. The next day, I received an email from the studio asking me to fix some bugs the developer was requesting I fix so he could carry on with the site. They were basically asking me to work more, for free, to enable him to walk off with the majority of the money and do less work. They also forwarded a suuuuuper shitty, condescending email from him, listing all the things he thought was wrong with the site (he even listed 'no favicon' although they'd never supplied a graphic for this). He also wrote a paragraph at the bottom EXPLAINING MY JOB TO ME and telling me:

I get the feeling you like to write Javascript, while being one of the easiest languages to learn, it can also be one of the hardest to master. While I applaud you for writing Vanilla JS, it looks like you have a general problem with structuring your application.

Not sure if I'm being oversensitive here but it felt so patronising, and i couldn't even go for an angry walk to get it out my system because of social distancing lol.

Let a girl quarantine in peace!!!!!!

tl;dr
You know that feeling when you have your headphones on and somebody is talking to you and then your stomach starts to hurt, because you don't want to put down your headphones because the music is great and your headphones plays it really good?

The post
I cannot code without headphones on. I'm currently on a longterm journey to find the best over-the-head budget headphones for coding, just out of curiosity, I started with cheap Phillips headphones for a couple of euros (9 or 10 i don't rem.), I would say they are usable, for a casual user, but far-far from the best

Then i purchased a Sennheiser HD451 for like 3x the price of the Phillips, really good. I use them in work and wanted to go on with the comparison so i bought a ATH m30x for home, and for gods sake, they are soo fucking good, way better what i would expect from a budget headphone, it cost twice the price of the Sennheiser.

Whats your "daily driver"? What would you suggest to try next?

note: before these I was using earbuds which came with my cellphones and 2.1 systems

The Odyssey of the Tenacious Tester:

Once upon a time in the digital kingdom of Binaryburg, there lived a diligent software tester named Alice. Alice was on a mission to ensure the flawless functionality of the kingdom's latest creation – the Grand Software Citadel.

The Grand Software Citadel was a marvel, built by the brilliant developers of Binaryburg to serve as the backbone of all digital endeavors. However, with great complexity came an even greater need for meticulous testing.

Alice, armed with her trusty testing toolkit, embarked on a journey through the intricate corridors of the Citadel. Her first challenge was the Maze of Edge Cases, where unexpected scenarios lurked at every turn. With a keen eye and a knack for uncovering hidden bugs, Alice navigated the maze, leaving no corner untested.

As she progressed, Alice encountered the Chamber of Compatibility, a place where the Citadel's code had to dance harmoniously with various browsers and devices. With each compatibility test, she waltzed through the intricacies of cross-browser compatibility, ensuring that the Citadel would shine on every screen.

But the true test awaited Alice in the Abyss of Load and Performance. Here, the Citadel's resilience was put to the test under the weight of simulated user hordes. Alice, undeterred by the mounting pressure, unleashed her army of virtual users upon the software, monitoring performance metrics like a hawk.

In the end, after days and nights of relentless testing, Alice emerged victorious. The Grand Software Citadel stood strong, its code fortified against the perils of bugs and glitches.

To honor her dedication, the software gods bestowed upon Alice the coveted title of Bug Slayer and a badge of distinction for her testing prowess. The testing community of Binaryburg celebrated her success, and her story became a legend shared around digital campfires.

And so, dear software testers, let the tale of Alice inspire you in your testing quests. May your test cases be thorough, your bug reports clear, and your software resilient against the challenges of the digital realm.

In the world of software testing, every diligent tester is a hero in their own right, ensuring that the digital kingdoms stand tall and bug-free.

An app I'm making for a client currently has 23 "pages" that are simply web views.
Most of those pages have A HREFS which open other pages (some external pages that I have no access to as a developer).
Of course, some of the links aren't HREFS and are javascript calls to change the content on the screen without going to another page. So the user thinks they have gone to another web page when then system doesn't recognise it as another page...
Additional to this, there are multiple versions of the pages depending on which language the user has selected in the app.

And nobody seems to have considered how the default back button handles all these possible eventualities (whether it can go back to previous web page, IF it was an HREF and not just JS mimicking a new page (and how would my webview even catch that), and of course IF the language hasn't changed during the user journey etc etc)

Am I wrong for being annoyed about this? Am I the dick for not developing a clean solution to it? Or am I justified because webviews have no place inside an app!

I'm sort of hoping apple deny this app due to too many web views :S

A very long rant.. but I'm looking to share some experiences, maybe a different perspective.. huge changes at the company.

So my company is starting our microservices journey (we have a 359 retail websites at this moment)

First question was: What to build first?

The first thing we had to do was to decide what we wanted to build as our first microservice. We went looking for a microservice that can be used read only, consumers could easily implement without overhauling production software and is isolated from other processes.

We’ve ended up with building a catalog service as our first microservice. That catalog service provides consumers of the microservice information of our catalog and its most essential information about items in the catalog.

By starting with building the catalog service the team could focus on building the microservice without any time pressure. The initial functionalities of the catalog service were being created to replace existing functionality which were working fine.

Because we choose such an isolated functionality we were able to introduce the new catalog service into production step by step. Instead of replacing the search functionality of the webshops using a big-bang approach, we choose A/B split testing to measure our changes and gradually increase the load of the microservice.

Next step: Choosing a datastore

The search engine that was in production when we started this project was making user of Solr. Due to the use of Lucene it was performing very well as a search engine, but from engineering perspective it lacked some functionalities. It came short if you wanted to run it in a cluster environment, configuring it was hard and not user friendly and last but not least, development of Solr seemed to be grinded to a halt.

Elasticsearch started entering the scene as a competitor for Solr and brought interesting features. Still using Lucene, which we were happy with, it was build with clustering in mind and being provided out of the box. Managing Elasticsearch was easy since there are REST APIs for configuration and as a fallback there are YAML configurations available.

We decided to use Elasticsearch since it provides us the strengths and capabilities of Lucene with the added joy of easy configuration, clustering and a lively community driving the project.

Even bigger challenge? Which programming language will we use

The team responsible for developing this first microservice consists out of a group web developers. So when looking for a programming language for the microservice, we went searching for a language close to their hearts and expertise. At that time a typical web developer at least had knowledge of PHP and Javascript.

What we’ve noticed during researching various languages is that almost all actions done by the catalog service will boil down to the following paradigm:

- Execute a HTTP call to fetch some JSON

- Transform JSON to a desired output

- Respond with the transformed JSON

Actions that easily can be done in a parallel and asynchronous manner and mainly consists out of transforming JSON from the source to a desired output. The programming language used for the catalog service should hold strong qualifications for those kind of actions.

Another thing to notice is that some functionalities that will be built using the catalog service will result into a high level of concurrent requests. For example the type-ahead functionality will trigger several requests to the catalog service per usage of a user.

To us, PHP and .NET at that time weren’t sufficient enough to us for building the catalog service based on the requirements we’ve set. Eventually we’ve decided to use Node.js which is better suited for the things we are looking for as described earlier. Node.js provides a non-blocking I/O model and being event driven helps us developing a high performance microservice.

The leap to start programming Node.js is relatively small since it basically is Javascript. A language that is familiar for the developers around that time. While Node.js is displaying some new concepts it is relatively easy for a developer to start using it.

The beauty of microservices and the isolation it provides, is that you can choose the best tool for that particular microservice. Not all microservices will be developed using Node.js and Elasticsearch. All kinds of combinations might arise and this is what makes the microservices architecture so flexible.

Even when Node.js or Elasticsearch turns out to be a bad choice for the catalog service it is relatively easy to switch that choice for magic ‘X’ or component ‘Z’. By focussing on creating a solid API the components that are driving that API don’t matter that much. It should do what you ask of it and when it is lacking you just replace it.

Many more headaches to come later this year ;)

The Turing Test, a concept introduced by Alan Turing in 1950, has been a foundation concept for evaluating a machine's ability to exhibit human-like intelligence. But as we edge closer to the singularity—the point where artificial intelligence surpasses human intelligence—a new, perhaps unsettling question comes to the fore: Are we humans ready for the Turing Test's inverse? Unlike Turing's original proposition where machines strive to become indistinguishable from humans, the Inverse Turing Test ponders whether the complex, multi-dimensional realities generated by AI can be rendered palatable or even comprehensible to human cognition. This discourse goes beyond mere philosophical debate; it directly impacts the future trajectory of human-machine symbiosis.

Artificial intelligence has been advancing at an exponential pace, far outstripping Moore's Law. From Generative Adversarial Networks (GANs) that create life-like images to quantum computing that solve problems unfathomable to classical computers, the AI universe is a sprawling expanse of complexity. What's more compelling is that these machine-constructed worlds aren't confined to academic circles. They permeate every facet of our lives—be it medicine, finance, or even social dynamics. And so, an existential conundrum arises: Will there come a point where these AI-created outputs become so labyrinthine that they are beyond the cognitive reach of the average human?

The Human-AI Cognitive Disconnection

As we look closer into the interplay between humans and AI-created realities, the phenomenon of cognitive disconnection becomes increasingly salient, perhaps even a bit uncomfortable. This disconnection is not confined to esoteric, high-level computational processes; it's pervasive in our everyday life. Take, for instance, the experience of driving a car. Most people can operate a vehicle without understanding the intricacies of its internal combustion engine, transmission mechanics, or even its embedded software. Similarly, when boarding an airplane, passengers trust that they'll arrive at their destination safely, yet most have little to no understanding of aerodynamics, jet propulsion, or air traffic control systems. In both scenarios, individuals navigate a reality facilitated by complex systems they don't fully understand. Simply put, we just enjoy the ride.

However, this is emblematic of a larger issue—the uncritical trust we place in machines and algorithms, often without understanding the implications or mechanics. Imagine if, in the future, these systems become exponentially more complex, driven by AI algorithms that even experts struggle to comprehend. Where does that leave the average individual? In such a future, not only are we passengers in cars or planes, but we also become passengers in a reality steered by artificial intelligence—a reality we may neither fully grasp nor control. This raises serious questions about agency, autonomy, and oversight, especially as AI technologies continue to weave themselves into the fabric of our existence.

The Illusion of Reality

To adequately explore the intricate issue of human-AI cognitive disconnection, let's journey through the corridors of metaphysics and epistemology, where the concept of reality itself is under scrutiny. Humans have always been limited by their biological faculties—our senses can only perceive a sliver of the electromagnetic spectrum, our ears can hear only a fraction of the vibrations in the air, and our cognitive powers are constrained by the limitations of our neural architecture. In this context, what we term "reality" is in essence a constructed narrative, meticulously assembled by our senses and brain as a way to make sense of the world around us. Philosophers have argued that our perception of reality is akin to a "user interface," evolved to guide us through the complexities of the world, rather than to reveal its ultimate nature. But now, we find ourselves in a new (contrived) techno-reality.

Artificial intelligence brings forth the potential for a new layer of reality, one that is stitched together not by biological neurons but by algorithms and silicon chips. As AI starts to create complex simulations, predictive models, or even whole virtual worlds, one has to ask: Are these AI-constructed realities an extension of the "grand illusion" that we're already living in? Or do they represent a departure, an entirely new plane of existence that demands its own set of sensory and cognitive tools for comprehension? The metaphorical veil between humans and the universe has historically been made of biological fabric, so to speak.