This is a serious, real thing. I’ve wasted countless hours of my life dealing with the XY problem. And be aware: this is NOT only a thing of the engineering world, this is everywhere. I’m almost completely sure that this is one of those things that upon reading about it, seeing the phenomenon in a few paragraphs of text, you’ll start to notice it every once in a while.

For your pleasure, please check out xyproblem.info.

The post The XY problem appeared first on Pietari Heino's personal website.

This discovery is not my own, but I find it most delightful.

The post }{{} vs. {}{} appeared first on Pietari Heino's personal website.

• Create a higher-order component (WithBaseEditor) that has its own styles (using withStyles from material-ui/JSS)
• Be able to override styles in the HOC from the wrapped component (ImageEditor/VideoEditor/ArticleEditor)
• Be able to easily test the HOC methods separated from the wrapped component

// BaseEditor.js
const baseEditorStyles = {...};

const WithBaseEditor = (Component, options = {}, overrideStyles = {}) => {
  class BaseEditor extends React.Component {
    ...
    baseEditorMethod() {} // this is "private"
    mutualMethod() {}
    ...
    render() {
      return (
      // some mutual jsx for layout
        <Component
          mutualMethod={this.mutualMethod}
        />
      );
    }
  }
  
  const enhanced = withStyles(overrideStyles)(withStyles(baseEditorStyles)(BaseEditor));

  enhanced.__Naked = BaseEditor;

  return enhanced;
};

export default WithBaseEditor;


// ImageEditor.js
import WithBaseEditor from 'BaseEditor';

const styles = {...};
class ImageEditor extends React.Component {...}

export default WithBaseEditor(withStyles(styles)(ImageEditor), options, styleConfig);

What happens in the code:
Create a HOC called WithBaseEditor that is implemented as a function that takes a component, some options, and styles. In the function body create a new class extending React.Component that implements what I call a BaseEditor that has got some private logic and some mutual logic. Private logic is never to be passed down to the component that is being wrapped whereas mutual logic is passed explicitly in the props. In order to use isolated styles for the BaseEditor, they’re defined in the HOC’s own file. In order to have some styling in the BaseEditor to be overwritten with customised styles “coming from” the wrapped component, they’re passed into the HOC function. What the HOC returns, finally, is BaseEditor, that is first wrapped with its own isolated styles defined in the same file and then re-wrapped with the styles passed in from the caller of the HOC. This way, the wrapped component, ImageEditor, can define its own styles and some styles that it wants to overwrite in the BaseEditor, and just call the HOC with carefully chosen arguments.

What’s that with the __Naked = BaseEditor?
Immediately before returning the enhanced component the actual BaseEditor class is injected into the returned component. This way BaseEditor is available bare/naked/whatever when you want to test it without involving wrapped component logic. You just pass in some dummy wrapped component and write the tests for the BaseEditor’s private methods.

The post Testing React HOC’s private logic appeared first on Pietari Heino's personal website.

https://arstechnica.com/gadgets/2018/12/dont-buy-a-5g-smartphone-at-least-not-for-a-while/

The post Read this for a nice view of the 5G landscape in 2019 appeared first on Pietari Heino's personal website.

When I was finishing the second part of the book I decided to write a short word on it on my blog. I started to feel that the book is actually too thin on material: it is not a complete story of Nokia from the beginning to the ALu merger but it is not only a business book either (at least in my opinion). I’m not sure what I expected but I started to feel that it’s a mixed bag in some way, not being able to clearly articulate my feelings. Now after finishing the book, I looked at the title and remembered that it actually is Transforming Nokia: The Power of Paranoid Optimism to Lead Through Colossal Change. I then realised that it is the perfect title for the book, it says it all. This is Nokia’s transformation told by Risto Siilasmaa with not only the story itself but filled with business and decision making bullets and ideas and whatnot – the Paranoid Optimism that he developed.

It is a very good and interesting book, I really did enjoy reading it.

The post Paranoid Optimist appeared first on Pietari Heino's personal website.

I’ve updated my TabJump Chrome extension, which lets you easily search through your open tabs from any windows, and jump into them. A longer explanation of the ideas and functionality of the extension may be found from my first blog posting about it, here.

This time around I’ve changed the core functionality of the extension to make it work more reliably and to enable better end-user customization. Now the extension’s UI is not drawn on top of the current page but instead it utilizes the usual popup container functionality of web extensions. It’s also possible to open it on a separate page, and when doing so, it is aware of its previous appearances and instead of spawning a multitude of TabJump tabs it always focuses on the living one.

The only missing feature as of now is history search. When you open up the search and try to find something that doesn’t exist as a tab on the machine, you need to close the extension, focus the URL bar, and type it in in there. This is of course not-optimal and a pain in the ass. The extension should do two things in a case of a missing match: first, suggest from your history and enable creation of a new tab based on user selection, and second, let you type any URL and hit enter to just get there.

The code is still very experimental and badly organized because of the experimental nature of the development (getting to know the web extension inner workings), and as such, not available anywhere. Also, some bugs might be hiding in the source. If you’d like to try out the extension, you can access it from this public link. When you install it, make sure you open Chrome’s extension shortcuts and map the two functions to some keys (my mappings are: CTRL+, opens the popup while CTRL+. opens the single tab view).

The post TabJump Chrome extension updates appeared first on Pietari Heino's personal website.

KDE Plasma 5.12 doesn’t come with the required functionality to get the window resized to half of the screen and positioned in the center so I needed to dig in to KWin scripting and do it myself. I now have three shortcuts that let me:

1. resize the current window to 1/2 of screen width and center it
2. grow it horizontally by 40 px
3. shrink it horizontally by 40 px

This is super useful – one button to get the size where it functions nicely 99 % of time and then a few pushes more to grow/shrink it if needed.

You may find my KWin script as a git repository that may be installed into your Plasma system with one command right here over at Github. The script itself is very simple and might even give you nice pointers on how to achieve something similar with the KWin’s scripting facilities. More details on KWin scripting (and Plasma UI manipulation) may be found from the official documentation.

The post Center current window in KDE Plasma appeared first on Pietari Heino's personal website.

Criterion-based grading, agile goals, and course (un)completion strategies: a visualization of a student’s learning path on TUT Programming 1 course. The Y-axis shows different automatically assessed programming tasks and the X-axisshows the rounds of the course (mapping to weeks on a semester). Colored balls are completed (the student’s solution passed the tests). Different colors represent different categories/levels of the tasks.

While working on a book chapter called Criterion-based grading, agile goals, and course (un)completion strategies (with Ihantola, Isohanni & Mikkonen) for a new Springer book that concentrates on agile learning strategies etc. we needed to generate lots of visualizations. The visualizations were supposed to show the completion paths of different students for the first programming course at Tampere University of Technology.

I took on the task and chose Python for scripting to digest all the data and transform it to a suitable format, D3.js for generating the actual visualizations, and Puppeteer to handle the generation and PNG saving of ~1000 visualizations.

The visualizations turned out pretty nice and the workflow was good. After nailing down the Python data digestion and what we even wanted from it, I played a ton with D3 and came up with a nice looking visualization. After we all agreed on how the thing should look like I used a simple Puppeteer script to turn everything into a nice directory hierarchy of lots of PNGs. I was happy that each of the steps were self-contained and didn’t depend on any of the other steps. My initial data was in CSV format and I used Python to go through it and dig out the needed bits and pieces. I made a simple visualization.html that contained all HTML, CSS, and JavaScript to display a single visualization, nothing more. I ran Python’s SimpleHTTPServer to serve the page on my localhost and to play with it until it looked nice. In the end I had a very simple Node.JS script that started Puppeteer which uses Headless Chrome browser in the background to do all sorts of webpage manipulation; Puppeteer went over every student’s data and loaded the visualization.html for all of them and turned to page into a PNG file.

I could have gone for all Python solution but I hadn’t had any reason to use Puppeteer before so this was a nice thing to tryout. Also, I had some experience from D3.js so it was much easier to come up with the visualization code using the library and the web instead of some Python plotting library or whatnot. We were happy with the results.

The post Using D3 and Puppeteer to generate visualizations appeared first on Pietari Heino's personal website.

I’ve been using this pattern with Nyssetutka.fi for quite a some time. The client loads more or less the minimum needed JS payload in order to get the UI going as fast as possible and then conditionally more if the user navigates to some specific views. This isn’t the complete truth and there are a couple of things I could do to make the initial payload even smaller but the gist of it is that not everything is loaded at once in the beginning.

The other day I 15 minutes of hard time googling around along the lines of the title of this blog posting. How would one lazy load the root component of a Vue application? Couldn’t find the answer anywhere so here it is:

const rootComp = () => import('./components/rootComp.vue');

new Vue({
  el: "#app-container",
  render: h => h(rootComp)
})

Now that I know the answer… it’s completely clear and logical that this is the way to do it. It’s the completely same syntax you would use for any other component lazy loading but here you just use it for the root component. But even if it’s kinda implicit that this is the way, the official Vue documentation nor any of the Vue lazy loading blog postings out there mention it. So here it is if someone else is looking for the info.

When could this be useful? The answer is not so clear if you compare it to lazy loading just normal components. They’re normal components not needed at the initialization of the app, right, but why would you lazy load the root, eh? If your app has multiple Vue instances and you don’t need them all either at the beginning or at all. In my case the app implements a notification popup telling about new updates and improvements to the site. The popup was easy to implement as a completely separate component used only by a separate Vue instance sharing the same Vuex store with the main app. So this was the way to do it – the popup itself is shown only to a small number of visitors, conditionally, and only once.

The post Lazy loading the Vue root component appeared first on Pietari Heino's personal website.

One thing that has *always* bothered me is battery life. No matter what phone I’ve been using the battery life has never been good. Doesn’t matter what sort of battery saving strategies I’ve been using (builtin, limiting services/apps etc.) or what resources the apps have been able to use, the juice has always run out surprisingly easily. At the same time some people around me have had *vastly* better experiences on their iDevices. That has sucked a big time.

This has now changed. Pixel 2 and the latest and greatest of the Google’s mobile OS deliver. I don’t have any numbers to share and am not interested in checking them up from the system stats since everything’s subjective and one person’s usage habits very rarely match anyone else’s. But I’m the type of user who wants to get multiple hours of screen time through various reading-this-and-that sessions, browsing the web to its bottom, and taking the phone into hand when you literally have to wait 35 seconds for the bus.

Pixel 2 running Oreo 8.1 has consistently delivered a MUCH BETTER battery life experience than *ANY* of my previous devices (first paragraph). This is not just a tad better, this is hugely better. The phone lasts so long that it has surprised me multiple times and had me over and again spontaneously praise it to my iGeeky brother. This is something totally different.

I really do hope this is more an advancement in the OS and not specific to the Pixel 2 hardware. If you’re interested, I really recommend to check out Ars Technica’s excellent deep-dive review of the new Google phones over here. The picture below is from their review and shows the excellence – at least in what I use my phone for, web browsing and stuff, not gaming. If you’ve got some insight or speculation to this happy matter, please share!

The post Android battery life: Pixel 2 and Oreo (8.1) nail it appeared first on Pietari Heino's personal website.