First impressions of ASUS X540UV

Leave a reply

Yesterday a new laptop arrived at home. It’s a budget one and I spotted a pretty good deal with 90 € off. I’ve decided for a purchase because the previous has been acting funny recently with on and off weird issues with display. It still works and does the job but with external monitor pluged-in. So it has became a stationary one which defeats the purpose of laptops.

The first think I observed was the lightness of a package. ASUS X540UV uses SSD and no DVD unit drive which lowers the total weight to 2 kilogams.

Next are ports: it has 3 for USB, 1 for HDMI, memory card and sound. Those are all on the left side. On the right side there’s nothing. The only thing I miss a little is a Ethernet port because it could come in handy from a time to time.

I have a little experiences with upgrading hardware components in a laptop (RAM) so I checked on a YouTube how would one open a laptop with similar internal design. Compared to my previous laptop, I have to say it’s less convenient. My previous laptop only required you to unscrew two screws and remove only a part of bottom surface to be able to add additional RAM but with the new one you have to remove the whole bottom surface and internally you have to unscrew some component, flip it, add RAM and repeat the process in reverse order. I decided not to do this myself since it’s not a pressing issue – my previous laptop had only 4 GB but new one has 8 GB.

On MobX Redux dilemma

Leave a reply

In my experiences using MobX as a state management library produces less code and lets you get things done quicker (two-folded knife!) but with Redux you get a lot of stuff for free – most notable is scalable approach to architecture and maintenance of web applications.

I personally prefer Redux also because it’s functional like React which puts a lot of emphasize on functional stateless components and it makes me feel like a JavaScript developer. While that means it’s more verbose, it contains minimal abstraction and thus is easier to debug.

Wolf Children review

Leave a reply

Japanese Wolf Children from 2012 may seem like a cartoon but this two-hour long animated movie deals with pretty adult themes.

It centers around mother who raises her two children in a remote house under the mountain and in the absence of their father. She’s doing everything in her power to learn new things and how to provide for her children despite their secrets which can make their life a lot more tougher if the world finds out about it.

I have really enjoyed the movie, also because the animation was really well made. It looked almost real, it did a good job mimicking the real world, especially nature movement.

It’s one of these movies that are excellent but completely overlooked. If you don’t know what I mean, just watch it first and than go to IMDb and note its score and number of votes.

New React Context API

Leave a reply

I like new react API for creating and using context. It feels right. One thing I immediately tried to do was creating a helper which simplifies consuming multiple contexts. Because they create context hell. When you component uses more than one context and because of a children as a function pattern (which is basically the same as render props pattern where component’s children function is specified as a component’s prop named render), code gets familiar indent to the left (callback hell).

For example with the use of this helper,

<Theme.Consumer>
    { theme => (
        <Language.Consumer>
            { language => (
                <App theme={theme} language={language} />
            )}
        </Language.Consumer>    
    )}
</Theme.Consumer>

would become

<Consume contexts={[Theme, Language]}>
    { (theme, language) => (
        <App theme={theme} language={language} />
    )}  
</Consume>

But after giving it a second thought, I realized in high-performance web applications this “multiple contexts consumer” case scenario can be a bad idea in most cases. Because If we have for example two contexts that are always used together, it’s better to just have one context anyway. But if a component uses more contexts which aren’t co-dependent, that means parts of component will be re-rendered unnecessary. So the component should be split into components which uses only one context or co-dependant contexts.

If you are interested in Consumer component, you can see it in following snippet with example usage. I’ve also added Provide component which mirrors Consume component for the sake of completeness. It’s no problem though if you specify Providers separately or not at all – in that case it will use context’s default value than).

Goroutines don’t panic if channel they write to is gone

Leave a reply

Couple of months ago I wrote an article about error handling in concurrent Go programs. One concern I had about it was if other goroutines would panic if some goroutine produces an error value which causes return from function when the channel is iterated with range construct.

So I made another program that mimics scenario. It spawns couple of goroutines, each taking a second more to complete than previous (for the sake of test being easier to observe). When done, they write to channel. 5th goroutine returns an error (after 5 seconds) via channel which is iterated using range. In case of an error, it’s returned from function.

package main

import (
    "errors"
    "sync"
    "time"
)

type data struct {
    err  error
    data int
}

func someWork(dataChan chan<- *data, collection []int) {
    var wg sync.WaitGroup
    l := len(collection)
    wg.Add(l)
    for i, e := range collection {
        go func(i, e int) {
            time.Sleep(time.Duration(i) * time.Second)
            var err error
            if i == 5 {
                err = errors.New("error")
            }
            dataChan <- &data{err, e}
            defer wg.Done()
        }(i, e)
    }
    wg.Wait()
    close(dataChan)
}

func someFunc() {
    collection := []int{1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1}
    dataChan := make(chan *data)

    go someWork(dataChan, collection)

    for c := range dataChan {
        if c.err != nil {
            return
        }
    }

    time.Sleep(2 * time.Second)
}

func main() {
    someFunc()
    time.Sleep(20 * time.Second)
}

It surprised me a little other goroutines which still aren't finished don't cause panic because channel is gone even. For more realistic test I've also added some work after someFunc is finished.

Don't know why, it sure has to do with the way garbage collection works in Go (would be a great read if there's detailed explanation of it). I'm glad though I don't have to deal with goroutines panicking myself.

One thing I didn't do in example is cancelling the work running goroutines are still doing so they stop wasting additional memory. One idiomatic way to do that is with the use of context package from standard library, which provides cancellation and timeout mechanisms.