I see go channels as a pipe connecting two air tight vacuum cleaners. One vacuum cleaner can not push anything into the pipe, if the other vacuum is not pulling from the pipe. Both need to do the opposite action. If one sends the “package” will be stuck until the other turns on it’s receiving action.
Channels can contain multiple slots for “holding” the “packages”.
Pushing more into the pipe than wha the pipe can handle results in a broken pipe.
I also think of it as a queue, first in, first out ( last in last out ). The only difference is this one is ultra sensitive and very particular.
We don’t think we have constraints as Software Engineers, but we actually do. Creating specifications is a great way to explore some of these constraints. See the full talk below by Kris Brandow at GopherCon 2018.
The first hurdle I faced was switching in December, what a weird time to switch right? I was supposed to be scaling down and focus on relaxation, but I thought the switch to be such a huge challenge, that It wouldn’t matter when I did it.
The second hurdle: I went cold turkey. I simply switched, printed out the new layout, gave it a solid glance and memorized all the new positions and kept it next to my desk. I watched my typing speed go from 35 WPM(words per minute) to 9. And my frustration levels go into the red.
I started to use this at work immediately. I warned my team mates and just jumped in. A good thing this sort of thing is encouraged at Automattic.
The two things that helped me the most during the first month was Type Fu and a supportive team.
With Type Fu you repeatedly type similar phrases until you “master the keys. At this point, you move on to the next level with more variation. It also has a setting to select the keys you battle with and only focus on them.
My current speed is 30 WPM. I use it as my default layout and I’m way more confident than I was a month ago. My main take away is that, if I can go from 9 -30WPM in a month then I’ll be more productive as time goes on.
I hope to increase this as I continue to practice every working day.
I always wanted to create a very simple WordPress based Todo App. After putting it off for a very long time I finally had the time to look into it.
The idea was a simple todo list that takes over your WP home page and relies on a standard to do post type for persistence. The interface should be driven by React using redux for state management. The result should be WordPress plugin that simply works without any configuration. The app works over the WordPress JSON REST API and must have a very simple UI framework.
1.Defining the data we need to store:
user – name and login details. For this, I cheated and simply use the WP login interface.
Todo item –with the ability to save details on a todo. For this, I use simply used a new post type. The title being the todo, the content being further information and post meta to store the state( completed/not completed )
2. Define the todo post type which we’ll use to store todo items. Each todo item relates to a post. You will notice that it’s not anything fancy but includes a few rest API configuration to make it easy for us to call posts at a later stage.
3. Setting up the JS system. I used Webpack to manage all frontend modules. I used yarn for package management and also Bable to allow me to use ES6 syntax.
4. For the UI framework, I used spectre as it is very light: https://picturepan2.github.io/spectre/
5. For user authentication, I used the user login and then relied on the WP cookie to allow the user to create todos over the REST API.
You can find the source code to play with here, it’s a wp plugin so you can install it:
I attempted this project mainly because wanted learn about all the new frontend tools. I mostly work in PHP and doing this was very refreshing. I’m inspired to do more of these. Even if no one ever needs it, I built it coz I wanted to.