Hi,
December 22nd 2005 was the day the first post under this blog came out.
The post was in Hebrew and back then it took a lot of effort to make Blogger display RTL languages well, which is what I babbled about most of the post.
It's amazing to believe that 10 years have gone by since then, with me shifting between technologies and employers, and even sacrificing my native tongue (and your delicate sense of grammar) so that this "thing" I've created can keep on living.
This blog has served me so well over the years, and keeps on doing so.
It is my stage for ranting and bashing technologies (and sometimes the people behind them). It is the place I use to keep learning and exploring more, sharing anything cool I see on the way or think about, without taking myself nor the industry too seriously.
This place, like a good journal, reminds me where I came from and where I wanna be. This blog, as the sub-title says, is my individual thought patterns (wink-wink, do you know where this line came from?) and I always find it amazing that you guys are reading this and finding it worth while.
So what's next?
Probably write some more :)
As you know, I don't write shit just for the sake of writing, and sometimes life courses leave me with little time to sit and shape sentences and ideas, but let me tell you this - this blog is still a passion I have that I don't see going away anytime soon. There are a lot of topics running in my mind which I can't wait to put on "paper".
I feel that 2016, and hopefully the years to follow, will be of more technology content, for I returned to my roots of coding and have new insights about the shift the industry is undergoing both technologically and conceptually.
One truth remains - I love making stuff, I love the creation process and this blog is just another brick it that wall.
Stay tuned guys...
Matti
January 02, 2016
October 06, 2015
Basic Webpack with ES6, JSX and React
Hi there,
I promised (sort of) on my twitter account that I will look into the integration of Webpack with ES6, JSX and React, you know, just because I read a little about Webpack and it does seems like a very nice solution for bundling JS modules and static assets while slicing them into chucks which can later be loaded on demand.
Before jumping into anything, a series of POC's is probably what you should do, so here is the first one on my behalf.
So how well and easy can Webpack be integrated with the latest out there, which is basically ES6 and React (but it does not have to be React. It can be pretty much anything)?
After playing with it for little less than an hour, I have a nice example which demonstrate how one can bring up a client to life, with ES6 and basic (I mean basic) react view, all this with the benefits of live reload. If that's interesting to you, keep reading:
BTW - All the code can be found on GitHub, so you can reference it along the way.
first off, I've created and empty folder and 'npm init' it.
Now I was able to install Webpack to the project (I generally don't install on the global scope, but you can if you have no fear of backward compatibility mess) along side with webpack-dev-server.
It is this webpack-dev-server which will enable me to listen to any change made on the source files, bundle them on the spot and render the page with the latest changes, no gulp, grunt or what-have-you involved.
Now I need a configuration file for Webpack, which defines which is the entry file, and what loaders participate on this compilation (among others). If you have no idea what those are, please read more about them on the Webpack site.
As you can see from many example on the web, the configuration file is using a CommonJS-like module system which is different than what ES6 is using, so if to be pure, the configuration file should also support the ES6 module system and for that we need to do 3 things:
Now we would like to start coding the actual stuff, which is in my case a simple "Hello React" component and render it to the DOM. I created a file for the component which has JSX for displaying the caption.
At this stage you are probably wondering what takes that lovely ES6 code (not to mention that lovely JSX) and converts it to plain old ES5 - well, for this we have the Babel webpack loader. We install it using npm again, and define it on the webpack configuration (check out the code on GitHub).
The entry file now imports that component I've just made and uses React to render it to the DOM, and that's about it.
Launching the web server using the webpack-dev-server we can now safely browse to localhost:8080/webpack-dev-server and see for our eyes the wonderful caption.
Now... let me see if I forgot anything. No. I think that I have all covered so far.
If you have any comments or questions you can comment below.
Hope this helps you :)
Cheers
I promised (sort of) on my twitter account that I will look into the integration of Webpack with ES6, JSX and React, you know, just because I read a little about Webpack and it does seems like a very nice solution for bundling JS modules and static assets while slicing them into chucks which can later be loaded on demand.
Before jumping into anything, a series of POC's is probably what you should do, so here is the first one on my behalf.
So how well and easy can Webpack be integrated with the latest out there, which is basically ES6 and React (but it does not have to be React. It can be pretty much anything)?
After playing with it for little less than an hour, I have a nice example which demonstrate how one can bring up a client to life, with ES6 and basic (I mean basic) react view, all this with the benefits of live reload. If that's interesting to you, keep reading:
BTW - All the code can be found on GitHub, so you can reference it along the way.
first off, I've created and empty folder and 'npm init' it.
Now I was able to install Webpack to the project (I generally don't install on the global scope, but you can if you have no fear of backward compatibility mess) along side with webpack-dev-server.
It is this webpack-dev-server which will enable me to listen to any change made on the source files, bundle them on the spot and render the page with the latest changes, no gulp, grunt or what-have-you involved.
Now I need a configuration file for Webpack, which defines which is the entry file, and what loaders participate on this compilation (among others). If you have no idea what those are, please read more about them on the Webpack site.
As you can see from many example on the web, the configuration file is using a CommonJS-like module system which is different than what ES6 is using, so if to be pure, the configuration file should also support the ES6 module system and for that we need to do 3 things:
- Install babel on the project using 'npm install babel --save-dev'
- Change the configuration file to export the module the way ES6 does
- Change the name of the configuration file to be "webpack.config.babel.js"
There you go, you're configuration is now pure ES6.
Now we would like to start coding the actual stuff, which is in my case a simple "Hello React" component and render it to the DOM. I created a file for the component which has JSX for displaying the caption.
At this stage you are probably wondering what takes that lovely ES6 code (not to mention that lovely JSX) and converts it to plain old ES5 - well, for this we have the Babel webpack loader. We install it using npm again, and define it on the webpack configuration (check out the code on GitHub).
The entry file now imports that component I've just made and uses React to render it to the DOM, and that's about it.
Launching the web server using the webpack-dev-server we can now safely browse to localhost:8080/webpack-dev-server and see for our eyes the wonderful caption.
Now... let me see if I forgot anything. No. I think that I have all covered so far.
If you have any comments or questions you can comment below.
Hope this helps you :)
Cheers
September 07, 2015
ES6, Babel and all between
So...
Keeping pace with the latest JS progress? it's mad, I know.
I would like however to talk about the fundamental staff which is changing under our feet, more precisely - ES6.
ES6 or ECMAScript 2015 (catchy, indeed...) was recently finalized and all the web is swarming about it, though the browsers do not fully support it, which is like showing a candy to a child but behind a glass window.
Thing is, that along side with it came the era of Transpilers with TypeScript and CoffeeScript standing out from the rest and for a long time I was trying to decide which path is more reasonable to follow.
I know that the comparison is not exactly symmetric, but you have to admit that ES6 can sometimes be seen as a mere transpiler especially when using Babel, though it is not... and TypeScript is gaining more and more popularity now that Angular decided to embrace it on their 2nd version, added to that VSCode which support TypeScript so nicely and you have a nice debate inside your head.
Having said all the above, I would like to share my reasons of why I think on going with ES6.
Now TypeScript can transpile their content into ES6, with features that keep on adding to the supported stack, but you need to realize that the process today will probably look like this -
TypeScript >> ES6 >> ES5
Since we said that browsers do not support the full spec and so we have to transpile ES6 to ES5, which does not make much sense to me.
Microsoft is the proud parent of TypeScript. Not that there is anything wrong with it, but it kinda makes you think of it's future, whereas ES6 is the De-facto ECMA standard which does not belong to anyone.
Don't know about you, but I remember some time ago that one Steve Jobs (and many top industry personas followed) said that having a proprietary technology is bad and this is one of the reasons Flash should be banned from the web. So why treat TypeScript any different?
This can mean that Microsoft might cease to support it, or go in a direction which fits it's own interests but not the common web development agenda.
You can look at GWT as Google's sort-of proprietary transpiler. Where the hell is it now?
If you don't know what Babel is please go and check it out. There is nothing too complex about it, just a simple tool which takes your ES6 and spits out ES5 on the other end. There are other tools which do that, but Babel seem to be the one growing on the community these days.
BTW - It's also very interesting to see how it implements the new ES6 capabilities into an old ES5 implementation.
One more thing - you can also run node on ES6 mode, with babel-node, which is cool cause you can start writing the backend in ES6 as well.
But please note - this is ES5 in the end, so what you're getting from it is just the chance to experience with ES6 and perhaps you will lose some performance over what Babel does with the code in order to convert it to ES5.
So basically, what I'm saying is this:
Soon all new JS code will be ES6 and browsers will support it to the fullest.
ES6 does not belong to any cooperation and you can start using it now, to the fullest, with tools like Babel, and later on, you will simply drop Babel from the stack and stay with the JS engine of your chosen platform.
You simply prepare for the future, with basically no risks... why not go there?
Do you feel I'm missing something here?
Do you have a reason not to start coding in ES6?
Please share...
Cheers
Keeping pace with the latest JS progress? it's mad, I know.
I would like however to talk about the fundamental staff which is changing under our feet, more precisely - ES6.
ES6 or ECMAScript 2015 (catchy, indeed...) was recently finalized and all the web is swarming about it, though the browsers do not fully support it, which is like showing a candy to a child but behind a glass window.
Thing is, that along side with it came the era of Transpilers with TypeScript and CoffeeScript standing out from the rest and for a long time I was trying to decide which path is more reasonable to follow.
I know that the comparison is not exactly symmetric, but you have to admit that ES6 can sometimes be seen as a mere transpiler especially when using Babel, though it is not... and TypeScript is gaining more and more popularity now that Angular decided to embrace it on their 2nd version, added to that VSCode which support TypeScript so nicely and you have a nice debate inside your head.
Having said all the above, I would like to share my reasons of why I think on going with ES6.
ES6 is not a Transpiler Syntax
Setting Babel aside for a minute, ES6 is the new standard of writing JS soon to be embraced with it's full capabilities by every browser which respects itself. This will not be a ES5 under the hood, but rather a JS engine which knows to read and execute the new syntax, with optimizations which come along. This is an important thing to understand, for most transpilers convert their syntax to plain ES5.Now TypeScript can transpile their content into ES6, with features that keep on adding to the supported stack, but you need to realize that the process today will probably look like this -
TypeScript >> ES6 >> ES5
Since we said that browsers do not support the full spec and so we have to transpile ES6 to ES5, which does not make much sense to me.
TypeScript is a proprietary Transpiler
Yes, you know it.Microsoft is the proud parent of TypeScript. Not that there is anything wrong with it, but it kinda makes you think of it's future, whereas ES6 is the De-facto ECMA standard which does not belong to anyone.
Don't know about you, but I remember some time ago that one Steve Jobs (and many top industry personas followed) said that having a proprietary technology is bad and this is one of the reasons Flash should be banned from the web. So why treat TypeScript any different?
This can mean that Microsoft might cease to support it, or go in a direction which fits it's own interests but not the common web development agenda.
You can look at GWT as Google's sort-of proprietary transpiler. Where the hell is it now?
Babel is cool
Damn it's cool.If you don't know what Babel is please go and check it out. There is nothing too complex about it, just a simple tool which takes your ES6 and spits out ES5 on the other end. There are other tools which do that, but Babel seem to be the one growing on the community these days.
BTW - It's also very interesting to see how it implements the new ES6 capabilities into an old ES5 implementation.
One more thing - you can also run node on ES6 mode, with babel-node, which is cool cause you can start writing the backend in ES6 as well.
But please note - this is ES5 in the end, so what you're getting from it is just the chance to experience with ES6 and perhaps you will lose some performance over what Babel does with the code in order to convert it to ES5.
So basically, what I'm saying is this:
Soon all new JS code will be ES6 and browsers will support it to the fullest.
ES6 does not belong to any cooperation and you can start using it now, to the fullest, with tools like Babel, and later on, you will simply drop Babel from the stack and stay with the JS engine of your chosen platform.
You simply prepare for the future, with basically no risks... why not go there?
Do you feel I'm missing something here?
Do you have a reason not to start coding in ES6?
Please share...
Cheers
March 03, 2015
Check it out - You Can't Be Great without Technical Excellence
Hi,
I wondered and bumped into this great presentation which again states what many of us already know but still wonder how come this is not common knowledge and practice.
This presentation is given by James Grenning, which I had no idea who he was prior to watching it, but it makes no difference...
The presentation can be found here.
James, after bubbling a little bit about agile, makes some strong points which even the thickest mind can grasp and relate to. To be honest, one's head should be really stuck in his rear bottom in order not to see the light James is talking about.
The mathematics of thinking before doing, TDD and code-quality is so evident it seems that this talk is redundant, but sadly it's not.
If you're impatient, allow me to point you to certain parts of the presentation which sums it nicely:
I wondered and bumped into this great presentation which again states what many of us already know but still wonder how come this is not common knowledge and practice.
This presentation is given by James Grenning, which I had no idea who he was prior to watching it, but it makes no difference...
The presentation can be found here.
James, after bubbling a little bit about agile, makes some strong points which even the thickest mind can grasp and relate to. To be honest, one's head should be really stuck in his rear bottom in order not to see the light James is talking about.
The mathematics of thinking before doing, TDD and code-quality is so evident it seems that this talk is redundant, but sadly it's not.
If you're impatient, allow me to point you to certain parts of the presentation which sums it nicely:
- 17:35m - WTF is a "hardening" period (which some of you may know as "stabilization" period)?
- 23:15m - Not doing TDD is like...
- 30:30m - What happens when practicing Development followed by Testing
- 55:55m - Yes, you are special but it does not matter.
- 1:01:10 - Motivating and De-motivation
February 10, 2015
Stop and Resume Binding in AngularJS
Hi,
There comes a time when you need to tweak the native behavior of a framework.
For me it was pretty straight forward desire to stop and resume binding for DOM elements.
The reason behind it was that sometimes I have several elements on the DOM which listen to the same data, but not all of them are viewable. Only one of them is viewable and this is the one I would like the binding to keep updating, while the rest shut the hell up and do nothing over the data changes.
AngularJs is not too kind when it comes to tempering with it's biding mechanism and I guess they have they reasons. The binding mechanism is something that can dramatically affect the performance of an application.
If you go little bit deeper (really, no too deep) you find that binding is all about the digest cycle which in turn invoke watchers, which are functions set to watch for changes and invoke callback accordingly. It is these $$watchers which you would like to remove and retrieve in order to connect and disconnect to the digest cycle.
I've made a simple POC where I created DOM with 2 identical directive bound to the same data on their parent scope. I also added buttons to toggle their binding - pressing it once cuts off the binding for a specific directive while the other keeps on updating. Another click resumes the binding.
Simple - you can find the code here on Plunker
Take care.
There comes a time when you need to tweak the native behavior of a framework.
For me it was pretty straight forward desire to stop and resume binding for DOM elements.
The reason behind it was that sometimes I have several elements on the DOM which listen to the same data, but not all of them are viewable. Only one of them is viewable and this is the one I would like the binding to keep updating, while the rest shut the hell up and do nothing over the data changes.
AngularJs is not too kind when it comes to tempering with it's biding mechanism and I guess they have they reasons. The binding mechanism is something that can dramatically affect the performance of an application.
If you go little bit deeper (really, no too deep) you find that binding is all about the digest cycle which in turn invoke watchers, which are functions set to watch for changes and invoke callback accordingly. It is these $$watchers which you would like to remove and retrieve in order to connect and disconnect to the digest cycle.
I've made a simple POC where I created DOM with 2 identical directive bound to the same data on their parent scope. I also added buttons to toggle their binding - pressing it once cuts off the binding for a specific directive while the other keeps on updating. Another click resumes the binding.
Simple - you can find the code here on Plunker
Take care.
January 27, 2015
Javascript Event Payload Preformance Effect
Hi,
I recently had a debate with one of my colleagues about why he shouldn't put redundant details on a Javascript event payload.
I strongly urged him to avoid putting information that no one needs just because it's there, and he claimed that it has no influence on the way the application work and preforms - which immediately lite up my "this is a task for JSPref" bulb.
You see, aside from being hard to maintain and in many times read and understand, having a lot of information over the event is simply slower than having less.
So just for the sake of your future debates over this, here is a JSPref I ran, where you can see that even clearer on FF.
Avoid redundant data transfer when possible :)
Events Payload Performance Effect JSPref
If you think this JSPref is not accurate feel free to fork it.
Cheers.
I recently had a debate with one of my colleagues about why he shouldn't put redundant details on a Javascript event payload.
I strongly urged him to avoid putting information that no one needs just because it's there, and he claimed that it has no influence on the way the application work and preforms - which immediately lite up my "this is a task for JSPref" bulb.
You see, aside from being hard to maintain and in many times read and understand, having a lot of information over the event is simply slower than having less.
So just for the sake of your future debates over this, here is a JSPref I ran, where you can see that even clearer on FF.
Avoid redundant data transfer when possible :)
Events Payload Performance Effect JSPref
If you think this JSPref is not accurate feel free to fork it.
Cheers.
January 20, 2015
Component Directive Options over Multiple Attributes
Hi guys,
When building a directive component in AngularJS you'd probably ask yourself - how will I expose the component's API to the "outer world". Putting "events" and "data" aside for this one, I want to focus on the components behavior configuration.
I would like to share a direction which I tend to go with, and that's using a single "options" or "config" object which pretty much controls all the behavior (not the data, but rather what to do with it) aspects of component.
Let's take for example a component directive which display a chart, a bubble chart for instance. I would like to tell this component what are the colors palette it should use, where to put the legend, how to distribute the ticks on the axis etc.
Now, the naive way of approaching this is to set attributes for this directive and say "colors" attribute will hold the colors array. the "ticksinterval" will hold the ticks configuration and so forth. Before you know if, your component looks like a very very long line on the DOM, with numerous attributes each, BTW, creates it's own watcher and effects the overall performance greatly (if you bind it to the scope, which you probably do).
That should be enough of a reason to consolidate all these configurations into a single object, but there is a catch here -
When I do this I avoid registering any reference to executable code on the configuration object. The rule of thumb I follow is: "treat this configuration object as a JSON file that later can be loaded from a distant server", doesn't know the code, no callbacks, nothing.
So he question might rise - how will I execute API's over this component? I would like to select a single bubble in this chart, how do I do that?
So again, think of this "selectedBubble" as an attribute you would normally put on the directives - something like "selectedIds" which receives an array of ID's and knows to track them down and mark them as selected on the chart.
That makes sense right? but wait - aren't we trying to avoid these multiple attributes? so instead, you've guessed it, put in on the configuration.
The component will know to read it from the configuration object and act upon it.
As with anything else, each "direction" or "rule" has it's exceptions and you should consider what suites the use-case best :)
Cheers
When building a directive component in AngularJS you'd probably ask yourself - how will I expose the component's API to the "outer world". Putting "events" and "data" aside for this one, I want to focus on the components behavior configuration.
I would like to share a direction which I tend to go with, and that's using a single "options" or "config" object which pretty much controls all the behavior (not the data, but rather what to do with it) aspects of component.
Let's take for example a component directive which display a chart, a bubble chart for instance. I would like to tell this component what are the colors palette it should use, where to put the legend, how to distribute the ticks on the axis etc.
Now, the naive way of approaching this is to set attributes for this directive and say "colors" attribute will hold the colors array. the "ticksinterval" will hold the ticks configuration and so forth. Before you know if, your component looks like a very very long line on the DOM, with numerous attributes each, BTW, creates it's own watcher and effects the overall performance greatly (if you bind it to the scope, which you probably do).
That should be enough of a reason to consolidate all these configurations into a single object, but there is a catch here -
When I do this I avoid registering any reference to executable code on the configuration object. The rule of thumb I follow is: "treat this configuration object as a JSON file that later can be loaded from a distant server", doesn't know the code, no callbacks, nothing.
So he question might rise - how will I execute API's over this component? I would like to select a single bubble in this chart, how do I do that?
So again, think of this "selectedBubble" as an attribute you would normally put on the directives - something like "selectedIds" which receives an array of ID's and knows to track them down and mark them as selected on the chart.
That makes sense right? but wait - aren't we trying to avoid these multiple attributes? so instead, you've guessed it, put in on the configuration.
The component will know to read it from the configuration object and act upon it.
As with anything else, each "direction" or "rule" has it's exceptions and you should consider what suites the use-case best :)
Cheers
July 13, 2014
Constatus - Find those Strings and Const'em!
Whud'up?
Not so long ago I've opened a random file on the code base I'm working with and saw the horror of many Strings values which have "why am I not a constant?!" written all over them.
I figured that a re-factor is in order but I wondered how will I know that if covered all the instances of a particular String value?
Good thing there is NodeJS around and some nice modules like Esprima, which can help with that, and so I found myself coding this little harmless tool which does the following:
Goes over the code and finds Strings which, according to configuration, should be made constants.
Deadly simple and dare I say dumb as it gets, but guys - it does the work, so why not put it on Github? ;)
So feel free to visit the project on Github with the mind-blowing name: Constatus
It is not complete, there are many more features that can be added, but it's out there for you to abuse ;)
Take care
Not so long ago I've opened a random file on the code base I'm working with and saw the horror of many Strings values which have "why am I not a constant?!" written all over them.
I figured that a re-factor is in order but I wondered how will I know that if covered all the instances of a particular String value?
Good thing there is NodeJS around and some nice modules like Esprima, which can help with that, and so I found myself coding this little harmless tool which does the following:
Goes over the code and finds Strings which, according to configuration, should be made constants.
Deadly simple and dare I say dumb as it gets, but guys - it does the work, so why not put it on Github? ;)
So feel free to visit the project on Github with the mind-blowing name: Constatus
It is not complete, there are many more features that can be added, but it's out there for you to abuse ;)
Take care
May 29, 2014
New Quake-Stats improvments
Yeah, I know - it has been a while since I wrote but trust me, I had important things to attend to, and still do BTW ;) don't worry, it has nothing to do with work, code or debugging shit.
Anyhow - I just wanted to let you know that the "quake-stats" open source application has gained some nice new features!
For those of you who don't know what I'm talking about, you can read about it here and of course visit the Git Hub repo.
So, we got MongoDB into the stack and so we can save games across time. Hold your horses, this doesn't mean that we have over-time game statistics but it means that we're on the way going there.
If you want to upload games files into the application there is an "easter egg" for you. Just go the to "/admin" route and before you will reveal itself a nice upload screen (well, not so nice but it does the work). Once uploaded, the game will be stored on your MongoDB and later can be accessed easily via the "Game" dropdown menu. This great feature is a contribution of Haim Litvak. Cheers mate!
I also added another feature to enable Quake scores over maps per a single player. This feature will display the score Quake calculates for each map and display it on the "player" screen under the "Kill, Deaths & Q-Score" chart.
That's it so far. If you think something is missing, fork it and do it yourself :)
Cheers
Anyhow - I just wanted to let you know that the "quake-stats" open source application has gained some nice new features!
For those of you who don't know what I'm talking about, you can read about it here and of course visit the Git Hub repo.
So, we got MongoDB into the stack and so we can save games across time. Hold your horses, this doesn't mean that we have over-time game statistics but it means that we're on the way going there.
If you want to upload games files into the application there is an "easter egg" for you. Just go the to "/admin" route and before you will reveal itself a nice upload screen (well, not so nice but it does the work). Once uploaded, the game will be stored on your MongoDB and later can be accessed easily via the "Game" dropdown menu. This great feature is a contribution of Haim Litvak. Cheers mate!
I also added another feature to enable Quake scores over maps per a single player. This feature will display the score Quake calculates for each map and display it on the "player" screen under the "Kill, Deaths & Q-Score" chart.
That's it so far. If you think something is missing, fork it and do it yourself :)
Cheers
April 27, 2014
My Sublime Text plugins
Yo.
I am pretty sure that many of you are familiar or even using Sublime Text.
If you don't you should definitely check it out and consider it being your main text/code editor.
One of it's key features is the plugins you can add to it, and so you can find numerous plugins which helps your coding process so much. I would like to share with you the very limited, yet so useful, set of plugins I use:
AngularJS
Something to help you code Angular better. Aside from code-completion it also offers a cool "goto definition" which helps greatly within AngularJS. Not to die for, but does makes things easier.
Brackets Highlighter
The name says it all. You want to know where you brackets start and end, surely if you're a web developer. This plugin hands it to you so you can stop looking for that missing bracket.
Git
Runs the basic Git operations from within Sublime Text. I'm not using this excursively since I prefer Git bash for these sort of things, but adding files, diffs and blame are darn easy and clearer with this plugin.
Git Gutter
You want to see your changes directly on the code (ok ok, on the code pane gutter). This plugin will let you do that. love it.
That's it.
Told you, I don't stack plugins just for the sake of having them. These 4 are the ones I use frequently and they are reliable.
I would love to hear any other plugins suggestions you might have that can make the work of a web developer much easier with Sublime Text.
… and BTW -
I don't know how many of you remember one of the brilliant Flash talents of all times - Mr. Grant Skinner. Anyhow, he has migrated to HTML5 development since and recently I've bumped into his RegExp tool for JS. I loved the previous version of that tool for ActionScript and this one is even better. A keeper.
Check it out - regexr
April 22, 2014
CrunchBang rocks #!
I'm not a Linux power-user. Correction, I'm not Linux user.
Seriously, I spent a lot of time laughing at those Linux fanatics, and still do. It always seemed to me that the more one likes Linux the more s/he has bad social skills.
But one thing has to said - Linux is a better OS for developers, period. If you're building stuff, if your'e contributing code to open source projects, if you like your shell to be efficient - it's Linux, mate.
So I found myself knocking on Ubuntu's doors and working for a fairly long time on it, struggling with it the way only a Win-OS user can.
Yet, something really bothered me with Ubuntu. The way it tried to be user friendly and in that course fucked up the UX or the way it offered me so many advanced features which I didn't want or cared about.
I have an old Toshiba Tecra laptop. It served me through thick and thin, suffered my abuses and even overcame some nicely done floor-crashes. I call it "the gimp", and my "gimp" had 2 OS's installed on it when I decided that it is time to wipe it clean and install a single one which can perform nicely.
Ubuntu was obviously the first choice, but then I can across a nice resource which presented a new linux debian distribution called "CrunchBang", or as the natives call it "#!".
After little exploration I came to know that it was a very light-weight OS, which works nicely on old machines - I had to give it a go.
The installation went briefly and in a matter of minutes I had it in front of me.
The interface minimalism is what got me first. No more task-bars and shit, just a blank desktop with the system monitors on and a set of keyboard shortcuts. beautiful.
Everything went faster, from opening the web browser to utilizing git on the shell - if it was a comics strip, I would add "SWOOSH!" to every operation I've made. And guys, I'm talking about and old machine with 3G of RAM and 2 Cores CPU. Insulting shit in today's terms.
I also have to mention that Ubuntu didn't approve my 2 monitors settings, which kinda sealed it's fate for me. What? install a plugin for that? yeah, right...
Of course I had to tweak the OS (yet) again, installing JAVA 1.7 (com'on, why does it have to be so annoying?!), installing languages and stuff, you know. But once I've done doing that, I was faced with a swift OS. simple as that. The "start" menu accessibility, the way OpenBox works for this OS, Sublime Text flying like an eagle over it... just sweet.
Imagine how it would perform on a new machine...
So if you're looking for a cool Linux distribution for your old machine, or just a cleaner OS which performs like a devil on the 7th pit of hell - I recommend you give this one a go.
… and BTW -
I caught this very inspiring deck of slides from HubSpot describing their culture. It's interesting to see how companies are aligning themselves to fit the present time.
Seriously, I spent a lot of time laughing at those Linux fanatics, and still do. It always seemed to me that the more one likes Linux the more s/he has bad social skills.
But one thing has to said - Linux is a better OS for developers, period. If you're building stuff, if your'e contributing code to open source projects, if you like your shell to be efficient - it's Linux, mate.
So I found myself knocking on Ubuntu's doors and working for a fairly long time on it, struggling with it the way only a Win-OS user can.
Yet, something really bothered me with Ubuntu. The way it tried to be user friendly and in that course fucked up the UX or the way it offered me so many advanced features which I didn't want or cared about.
I have an old Toshiba Tecra laptop. It served me through thick and thin, suffered my abuses and even overcame some nicely done floor-crashes. I call it "the gimp", and my "gimp" had 2 OS's installed on it when I decided that it is time to wipe it clean and install a single one which can perform nicely.
Ubuntu was obviously the first choice, but then I can across a nice resource which presented a new linux debian distribution called "CrunchBang", or as the natives call it "#!".
After little exploration I came to know that it was a very light-weight OS, which works nicely on old machines - I had to give it a go.
The installation went briefly and in a matter of minutes I had it in front of me.
The interface minimalism is what got me first. No more task-bars and shit, just a blank desktop with the system monitors on and a set of keyboard shortcuts. beautiful.
Everything went faster, from opening the web browser to utilizing git on the shell - if it was a comics strip, I would add "SWOOSH!" to every operation I've made. And guys, I'm talking about and old machine with 3G of RAM and 2 Cores CPU. Insulting shit in today's terms.
I also have to mention that Ubuntu didn't approve my 2 monitors settings, which kinda sealed it's fate for me. What? install a plugin for that? yeah, right...
Of course I had to tweak the OS (yet) again, installing JAVA 1.7 (com'on, why does it have to be so annoying?!), installing languages and stuff, you know. But once I've done doing that, I was faced with a swift OS. simple as that. The "start" menu accessibility, the way OpenBox works for this OS, Sublime Text flying like an eagle over it... just sweet.
Imagine how it would perform on a new machine...
So if you're looking for a cool Linux distribution for your old machine, or just a cleaner OS which performs like a devil on the 7th pit of hell - I recommend you give this one a go.
… and BTW -
I caught this very inspiring deck of slides from HubSpot describing their culture. It's interesting to see how companies are aligning themselves to fit the present time.
April 17, 2014
Printing a Dialog content using Canvas and iFrame
Hi guys,
You know that printing from the browser is a bitch. Even after you've figured out how to put the content you want into the browser, the printing doesn't always work the same on all the browsers (yes! HTML is a standard... my arse). And that's not where all the trouble stop but anyway...
The problem I would like to bring up in this post is printing from a dialog box, which is more complex since we have to somehow extract the visual data from the dialog and then put it in some way that the crippled window.print() method can make sense of it. I mean seriously, have you ever seen such a lame API? print()? that's it? no "what do you want to print?". Throw me a freaking bone here.
Given that we're dealing with a dialog kinda eliminates the possibility to use the print media query, since we're not going to alter the whole page, just a section of it.
I saw many solutions on the web, some offering to save and then clean up the DOM, attach a cloned version of the DOM you actually want to print, and then re-render it all back after printing, which to me sounds like "bla bla bla bad performance sad users bla bla bla".
You know, all kinds of adding classes to elements, removing it then later... oh god.
Of course there is the jQuery plugin which offers to do that but I wasn't in the mode to introduce yet another jQuery pluging so I had to think of something else...
Canvas came to the rescue.
The idea I came up with is to somehow capture the DOM content I wanted to print, convert it into an image, and then create a hidden iFrame bearing the content of this image among other stuff I wanted to be printed. How? canvas can be concerted into an image.
I already had html2canvas library so it wasn't in a need to download any other 3rd party. you can get what it does from it's name, right? good.
Moving forward, here's the actions the code needed to perform (pseudo-code):
As for printing the iFrame itself I took a code snippet from some stackoverflow thread but I had to tweak it a bit since Firefox didn't like what I did, for it removed the iFrame before the browser launched it's printing. To overcome this I've used a deferred object, like so:
and this means that I had to listen to the promise in order to remove the iframe from the DOM and not just count on the fact the window.print() is supposed to stop javascript execution...
I think that pretty much sums it up. It might not be the best idea out there so I would love to hear your opinion on it or better if you have a better one.
… and BTW -
I caught this nice AngularJS Weekly magazine (or whatever you would like to call it) on the way. A lot of cool resources and stuff. Pretty nice.
Stay tuned and play on.
You know that printing from the browser is a bitch. Even after you've figured out how to put the content you want into the browser, the printing doesn't always work the same on all the browsers (yes! HTML is a standard... my arse). And that's not where all the trouble stop but anyway...
The problem I would like to bring up in this post is printing from a dialog box, which is more complex since we have to somehow extract the visual data from the dialog and then put it in some way that the crippled window.print() method can make sense of it. I mean seriously, have you ever seen such a lame API? print()? that's it? no "what do you want to print?". Throw me a freaking bone here.
Given that we're dealing with a dialog kinda eliminates the possibility to use the print media query, since we're not going to alter the whole page, just a section of it.
I saw many solutions on the web, some offering to save and then clean up the DOM, attach a cloned version of the DOM you actually want to print, and then re-render it all back after printing, which to me sounds like "bla bla bla bad performance sad users bla bla bla".
You know, all kinds of adding classes to elements, removing it then later... oh god.
Of course there is the jQuery plugin which offers to do that but I wasn't in the mode to introduce yet another jQuery pluging so I had to think of something else...
Canvas came to the rescue.
The idea I came up with is to somehow capture the DOM content I wanted to print, convert it into an image, and then create a hidden iFrame bearing the content of this image among other stuff I wanted to be printed. How? canvas can be concerted into an image.
I already had html2canvas library so it wasn't in a need to download any other 3rd party. you can get what it does from it's name, right? good.
Moving forward, here's the actions the code needed to perform (pseudo-code):
- Get the canvas from the HTML elements
- Convert the canvas to an image using the toDataURL('image/png') method
- Create an iFrame dynamically
- Append the iFrame to the DOM
- Once loaded Set the iframe content with the newly generated image I have
- Send it to printing, by printing the iFrame content only
- Smoke a cigarette
As for printing the iFrame itself I took a code snippet from some stackoverflow thread but I had to tweak it a bit since Firefox didn't like what I did, for it removed the iFrame before the browser launched it's printing. To overcome this I've used a deferred object, like so:
this.printIframe = function (id) {
var deferred = $q.defer(),
iframe = $window.frames ? $window.frames[id] : $window.getElementById(id),
ifWin = iframe.contentWindow || iframe;
ifWin.focus();
ifWin.print();
deferred.resolve('done');
return deferred.promise;
};
and this means that I had to listen to the promise in order to remove the iframe from the DOM and not just count on the fact the window.print() is supposed to stop javascript execution...
I think that pretty much sums it up. It might not be the best idea out there so I would love to hear your opinion on it or better if you have a better one.
… and BTW -
I caught this nice AngularJS Weekly magazine (or whatever you would like to call it) on the way. A lot of cool resources and stuff. Pretty nice.
Stay tuned and play on.
April 12, 2014
All the JS you need
Yo guys,
You know me, I'm just strolling around the web bumping into nice stuff on the way, and recently I found a great place where you can pretty much get all the knowledge sources you need for JS.
To be honest, it's pretty amazing how much one can gather about this Egyptian-pyramids-fucking-papyrus-deserved scripting language, but then again we must, now don't we? :)
Enjoy it: superhero.js
You know me, I'm just strolling around the web bumping into nice stuff on the way, and recently I found a great place where you can pretty much get all the knowledge sources you need for JS.
To be honest, it's pretty amazing how much one can gather about this Egyptian-pyramids-fucking-papyrus-deserved scripting language, but then again we must, now don't we? :)
Enjoy it: superhero.js
April 07, 2014
Delegating Event handlers to align Event Data model
After
such a pretentious title we can all stop and take a
one week sleep. WTF do I want from you now, you probably ask. yeah, ok. check this out:
Think about this
next situation - You have a nice component which potentially can host several
other components, each can dispatch a different event, an event that needs to
be handled of within the "parent" component.
We cannot let the
"parent" component manage all the events potentially fired from its
nested components, right? I mean, we can let it but then we will pretty much
shit into our own development experience and maintenance, after all, we want the "parent"
component to be aware of a single Event data model.
Being aware of a
single event data model means that the "parent" component will expect
a single format of data when receiving events from any of its nested components. It
will not matter what's the data model of each nested component, something will have
to align it into a single well-known model. The question is who?
We need some kind of
a delegator, which will know all the potential events and will process their
data and send a nice formatted data back to the "parent" component.
So, if we are to
drill into more details, we're actually talking about extending the
"parent" component's Scope, since it is that Scope which will
eventually listen to all these events, but it will be done in a sort of a
"mixin" approach.
The solution I came
up with introduces a service which has a single method registering the
"parent" component's scope. From there on, the service will extend
the Scope and eventually send an event back to the "Parent" component
with the processed event data.
Simple does it.
The POC can be found
in Plunker
I would love to hear
if you have any comments about it.
Cheers
April 03, 2014
My Unit Testing Approach to JavaScript
Hi guys,
I thought it would be nice to share with you my approach to JavaScript unit testing.
It's not really bound to any particular technology so you can embrace it if you think it can bring you some peace.
Do you have a different approach?
… and BTW -
I've bumped into this nice online tool which helps assessing 3rd party JS libraries.
Check it out at jscritic
Stay tuned.
I thought it would be nice to share with you my approach to JavaScript unit testing.
It's not really bound to any particular technology so you can embrace it if you think it can bring you some peace.
- Configure a threshold time of each test to be less than 500ms. I hate to wait on code. I need feedback now.
- I feel really bad when I need to write test for a already written code. It misses the whole purpose and usually results in bad testing. I thrive to always write tests first and code later. Close the gap you have, and start working the right way.
- Start from high-level "it"s describing what you want to test do check, so the result will be a set of empty "it" functions describing the expected functionality.
- Launch a watcher on the test files. This is crucial for having immediate feedback to whatever you're writing.
- For me, I launch the grunt serve task (Yeoman) which let's me see the application running while monitoring the tests. The Karma runs as a part of it and while keeping the autoWatch parameter as true, each save is triggering the tests. I'm always testing and seeing that the application doesn't break.
- Writing minimal code to fix the test is so important. We, developers and mostly architects, have the tendency to think far and beyond. Stop it. I'm fixing only what is required. At least I try to… ;)
- If I see that a group of tests should be bound together under some functional context, I do that by adding nested "describe"s.
- I'm always making sure that the description for the tests make sense as a real sentence which anybody can understand, even fishmongers.
- Test is first citizen code. Have JSHint/JSLint prob on your test code as well.
- I want to see my coverage all the time. It gives me satisfactory and a warm pat on the back, but seriously now, I got to have some indication as to how good am I doing and whether I cover all the branches important to me.
Do you have a different approach?
… and BTW -
I've bumped into this nice online tool which helps assessing 3rd party JS libraries.
Check it out at jscritic
Stay tuned.
April 01, 2014
Mocking a Confirmation Dialog in AngularJS Unit-Testing
What is more convenient then talking about the shallow gratification tests give us in the previous post, and now posting about testing examples. What can I say, you got me, I'm a child ;)
Anyhow, lets take the following case: User wishes to delete some book from his library, once he presses the delete button a confirmation dialog pops up to ask him if he is stupid or not, and once he approve that he is, the entity is being deleted.
Now, some of you may jump and shout that this is no unit! this is an automation test par excellence, but I would have to shut them up and say that yeah, this should also be tested in automation but there are unit aspects that need to be checked as well. let me explain-
You controller will probably contain 2 methods:
- confirmBookDeletion - which pops the dialog
- deleteBook - which actually deletes the book
If we will break it down, the process is: display a dialog with a certain caption to it, wait for that dialog "promise" and act according to the decision (in our case "yes" invokes the deletBook method).
how do you do that? that's right, you mock it. but how?
Obviously you have some sort of a DialogService which makes your work mach easier, and on it you have a nice "confirm(msg)" method which does what take, but how exactly are you going to mock it? it's not just making sure that DialogService.confirm(msg) was called but it has to return a promise which you can later work with. It's actually pretty straight forward
First thing, let's create a MockDialogService. We do that for the sake of spying after it's confirm method:
MockDialogService = {
confirm: function(msg) {
}
};
So now you can spy on this method, but here is the nice trick - by spying on it you can define what returns when you call it, and in our case we would like to return a resolved promise with the value of "yes" (cause this is what we're testing now):
var deferred = $q.defer();
deferred.resolve('yes');
spyOn(MockDialogService, 'confirm').andReturn({result:deferred.promise});
Now that we have that we can make our expectation from it, like so:
expect(MockDialogService.confirm).toHaveBeenCalledWith('Are you out of your mind?!');
Nice. Now we need to see how this invokes the deleteBook method. so we spy on it:
spyOn(yourCtrl, 'deleteBook');
And here comes the tricky part. Since promises will be executed on the next Angular Digest cycle, we need to trigger it. We do this with scope.$apply(). After that we can expect that the deleteBook() method will be called:
scope.$apply(); expect(ctrl.deleteBook).toHaveBeenCalled();
Cheers
March 26, 2014
Understand why
So - You writing code in a TDD manner, which means that basically you're writing the tests first, waiting on them to fail, and then writing the code which makes them pass.
Damn, This makes you feel so good, right? It's like a fucking rush of satisfactory that runs through you, making you feel like you're fulfilling your roll in the world, you're executing your work to the max. You tell yourself that hey! You can do that forever. No, seriously - FOREVER.
But have you ever wondered why you feel this way?
What exactly taps into our, some-might-claim, childish emotions and pats us so warmly on the back?
Most of us feel this way and usually don't give a flying fuck about the end product, not to mention the end user of the software their creating, and this puzzles me greatly - what makes some of the smartest people I know develop such an addiction to this an immediate, shallow gratification feeling?
Let me try to ware the psychoanalyst hat for a sec and make some assumption on why a developer feels so good about a passing test and try to drilldown to find the true nature behind this behavior
Is it the quality?
Sadly I would have to say it is rarely the quality increase which makes developers so satisfied with a passing test. I saw many tests which don't check anything and pass successfully, leaving their author happy like pig-in-shit with the work he has done. In some cases developers would even knowingly cheat to make a test pass, although they will later claim that this has damaged their satisfaction since our conscience cannot be tricked that easily. Sadly The build can.
Personally I believe that the motivation for tests should come from the desire for quality. Why you desire quality? Because you want your customers to enjoy and have value from using your product.
Is it the game?
Writing software in TDD is very much like playing a self-game. It's like you're challenging yourself, much like playing Solitaire, putting targets and then trying to hit them with a stone from afar. And you have monitoring which kind of represent a leader board where you can see how much targets you did hit (coverage), which sometimes brings developer to an absurd state where their testing meaningless chunks of code like Getter/Setter just to have their coverage up.
The game does have contribution to developers satisfactory, but playing it without seeing the big picture can sometimes distract you from the real goal, that is making the end product better for the user. After all, all your code can be covered with tests and you will be top of the list, but the product doesn't sell because it is a piece of crap. Better start packing your cubical up cause your company went broke, but hey, don't forget to take the leader board with you!
Is it the mini-goals?
You know these lovely "todo" lists? Research have shown that people enjoy "checking" a task as done so much, that sometimes they register task they've already completed just to have a "check" next to it, while other tasks that really needs to be attended are left neglected. You know what I'm talking about… yes, you do.
Same with the tests. You set up small tasks to be completed, e.g. "should fetch user information" and you right away start working on it in order to put a "check" over it. You like it so much that sometime your tests become meaningless and have no benefit to the code quality or maintenance.
Is it our perfectionism?
You love to see thing done to perfection. Most of us who deal with software do (some don't and they should get fired. I mean - now). So you look at your coverage report and you eye starts to twitch for you see that you're missing 3% to your 100% code coverage. You don't mind that the code is well tested and that 3% is redundant and having them tested will not benefit the code whatsoever. You want to reach that 100%. A sheer waste of your time and build time, but damn - I just have to get this thing 100% green.
Tests are not the goal, they are the means
Yeah, let's remind ourselves once again that tests are the means in getting our goal which is a good and maintainable product releases. No seriously, you have to stop dancing around glorifying the hammer you're holding when all you have built with it is a huge pile of horseshit.
And for that matter, I strongly believe that developers should stop alienating themselves from the product. It's not only the tests which are the means but the code itself. It is your means for creation. The paint of your brash, the nail and hammer. We should concentrate on the painting. You have never seen a child showing off his color palate to his parents, right?
So why then?
Because it's easy and well defined.
If you look closely at the tasks you've recently had you'll find it that you tend to avoid those which are hard to complete or those which you have a vague idea on how to accomplish them. Tests are neither. Tests are well defined tasks which are basically easy to complete. Of course you like doing them. Hell, you're even get credits if you make a lot of them.
Why the hell won't you write them like crazy?
Conclusion
Tests are good. Write them. Responsively.
You're not a monkey. Always question the world around you and try to understand… why.
Damn, This makes you feel so good, right? It's like a fucking rush of satisfactory that runs through you, making you feel like you're fulfilling your roll in the world, you're executing your work to the max. You tell yourself that hey! You can do that forever. No, seriously - FOREVER.
But have you ever wondered why you feel this way?
What exactly taps into our, some-might-claim, childish emotions and pats us so warmly on the back?
Most of us feel this way and usually don't give a flying fuck about the end product, not to mention the end user of the software their creating, and this puzzles me greatly - what makes some of the smartest people I know develop such an addiction to this an immediate, shallow gratification feeling?
Let me try to ware the psychoanalyst hat for a sec and make some assumption on why a developer feels so good about a passing test and try to drilldown to find the true nature behind this behavior
Is it the quality?
Sadly I would have to say it is rarely the quality increase which makes developers so satisfied with a passing test. I saw many tests which don't check anything and pass successfully, leaving their author happy like pig-in-shit with the work he has done. In some cases developers would even knowingly cheat to make a test pass, although they will later claim that this has damaged their satisfaction since our conscience cannot be tricked that easily. Sadly The build can.
Personally I believe that the motivation for tests should come from the desire for quality. Why you desire quality? Because you want your customers to enjoy and have value from using your product.
Is it the game?
Writing software in TDD is very much like playing a self-game. It's like you're challenging yourself, much like playing Solitaire, putting targets and then trying to hit them with a stone from afar. And you have monitoring which kind of represent a leader board where you can see how much targets you did hit (coverage), which sometimes brings developer to an absurd state where their testing meaningless chunks of code like Getter/Setter just to have their coverage up.
The game does have contribution to developers satisfactory, but playing it without seeing the big picture can sometimes distract you from the real goal, that is making the end product better for the user. After all, all your code can be covered with tests and you will be top of the list, but the product doesn't sell because it is a piece of crap. Better start packing your cubical up cause your company went broke, but hey, don't forget to take the leader board with you!
Is it the mini-goals?
You know these lovely "todo" lists? Research have shown that people enjoy "checking" a task as done so much, that sometimes they register task they've already completed just to have a "check" next to it, while other tasks that really needs to be attended are left neglected. You know what I'm talking about… yes, you do.
Same with the tests. You set up small tasks to be completed, e.g. "should fetch user information" and you right away start working on it in order to put a "check" over it. You like it so much that sometime your tests become meaningless and have no benefit to the code quality or maintenance.
Is it our perfectionism?
You love to see thing done to perfection. Most of us who deal with software do (some don't and they should get fired. I mean - now). So you look at your coverage report and you eye starts to twitch for you see that you're missing 3% to your 100% code coverage. You don't mind that the code is well tested and that 3% is redundant and having them tested will not benefit the code whatsoever. You want to reach that 100%. A sheer waste of your time and build time, but damn - I just have to get this thing 100% green.
Tests are not the goal, they are the means
Yeah, let's remind ourselves once again that tests are the means in getting our goal which is a good and maintainable product releases. No seriously, you have to stop dancing around glorifying the hammer you're holding when all you have built with it is a huge pile of horseshit.
And for that matter, I strongly believe that developers should stop alienating themselves from the product. It's not only the tests which are the means but the code itself. It is your means for creation. The paint of your brash, the nail and hammer. We should concentrate on the painting. You have never seen a child showing off his color palate to his parents, right?
So why then?
Because it's easy and well defined.
If you look closely at the tasks you've recently had you'll find it that you tend to avoid those which are hard to complete or those which you have a vague idea on how to accomplish them. Tests are neither. Tests are well defined tasks which are basically easy to complete. Of course you like doing them. Hell, you're even get credits if you make a lot of them.
Why the hell won't you write them like crazy?
Conclusion
Tests are good. Write them. Responsively.
You're not a monkey. Always question the world around you and try to understand… why.
November 24, 2013
Avoiding Angular's Digest Cycles Limit Reached
Hi guys,
I've recently encountered an issue where in a certain view on an Angular application I've reached the digest cycle limit. If you got here, 80% that you've reached the same issue yourselves.
I would like to elaborate here on how I've managed to avoid it, and fix the issue. It might not work for all the variation of this problem, but it is worth trying before you go into more serious measures.
Avoid calling processing-function from the view
I’m talking about manipulating data from the view in order for it to suite the view needs, e.g. ng-repeat=”value in yourFunction(scopeMemeber)”
If you need to manipulate the data for your view, do it on the logic tier, which is the controller.
Try to use only $scope member directly on the view.
When preparing data on the controller, avoid referencing $scope members up until the very end
If you’re getting a value from some service and on the controller you’re start to “work” on it, try to avoid referencing $scope members in it, since any change to them is a potential dirty-check loop.
What you want to do is try and save the assignment to the $scope member to the very end. Manipulate you’re data using plain JS, and only in the end make the assignment to the $scope member.
Note that sometimes it would even be more efficient to copy an Object, just to make sure it is not linked to the $scope anymore…
Put Sorting, Filtering, etc. outside of the view if possible
Although Angular offers nice ways to sort, order, filtering, etc. as a part of their API on the view level, I would be much better to do that on the logic tier (controller) when the view is complex and have a lot of these.
It is sometimes more efficient to order and array and assign it to the $scope member again, than to do it on the view.
If you have more suggestion, I would be happy to hear about it :)
Cheers
I've recently encountered an issue where in a certain view on an Angular application I've reached the digest cycle limit. If you got here, 80% that you've reached the same issue yourselves.
I would like to elaborate here on how I've managed to avoid it, and fix the issue. It might not work for all the variation of this problem, but it is worth trying before you go into more serious measures.
Avoid calling processing-function from the view
I’m talking about manipulating data from the view in order for it to suite the view needs, e.g. ng-repeat=”value in yourFunction(scopeMemeber)”
If you need to manipulate the data for your view, do it on the logic tier, which is the controller.
Try to use only $scope member directly on the view.
When preparing data on the controller, avoid referencing $scope members up until the very end
If you’re getting a value from some service and on the controller you’re start to “work” on it, try to avoid referencing $scope members in it, since any change to them is a potential dirty-check loop.
What you want to do is try and save the assignment to the $scope member to the very end. Manipulate you’re data using plain JS, and only in the end make the assignment to the $scope member.
Note that sometimes it would even be more efficient to copy an Object, just to make sure it is not linked to the $scope anymore…
Put Sorting, Filtering, etc. outside of the view if possible
Although Angular offers nice ways to sort, order, filtering, etc. as a part of their API on the view level, I would be much better to do that on the logic tier (controller) when the view is complex and have a lot of these.
It is sometimes more efficient to order and array and assign it to the $scope member again, than to do it on the view.
If you have more suggestion, I would be happy to hear about it :)
Cheers
September 29, 2013
Flashmatticomponents now on GitHub
Hi guys,
It took 1 email from a developer who contacted me about my old Flex/Air open source project called Flashmatticomponent, which made me finally take the time and migrate this project from Google Code to GitHub.
I don't know how many of you are still interested in the murdered-by-Adobe-and-Apple technology called Flex, but if you do, I bet you can make use of it.
I, myself, am really proud of this project ;)
You can find it here:
https://github.com/mbarzeev/flashmatticomponents
I've also copy-pasted the Wiki pages, but it didn't turned out so well, and to be honest, I can't be bothered with fixing it right now, so sorry about that.
Enjoy.
It took 1 email from a developer who contacted me about my old Flex/Air open source project called Flashmatticomponent, which made me finally take the time and migrate this project from Google Code to GitHub.
I don't know how many of you are still interested in the murdered-by-Adobe-and-Apple technology called Flex, but if you do, I bet you can make use of it.
I, myself, am really proud of this project ;)
You can find it here:
https://github.com/mbarzeev/flashmatticomponents
I've also copy-pasted the Wiki pages, but it didn't turned out so well, and to be honest, I can't be bothered with fixing it right now, so sorry about that.
Enjoy.
September 04, 2013
Quake III Arena - Statistics including Flags
Hi guys,
It is a tradition for us, to drop everything and play Quake III Arena, CTF mode, on every Thursday. Now, we did have some statistics showing each players kills etc. but we never had something to show statistics for Flags. How many did one fetched, how many did he score? did he restored any? you know... what really counts when you're playing CTF.
I looked for something on the web but couldn't find anything (if you know of any solution I'll be happy to know), so I've opened the log file and went through it to see if there is anything that might help me.
Apparently the log does mention the Flags but in such manner that it is really hard to understand in what status is the flag. You can't find anything resembling "Score" or "Fetch" but rather entries where the flag has been "touched" by a player.
To make a long story sort, I came up with a simple algorithm to resolve the Flags status, and having achieved that, the rode for creating an Angular/Node/Express (using Yeoman) application was easy.
I've uploaded that application source to Github and you can find it here:
quake-stats, an open source project
Feel free to download and use, and of course, if you feel that something is missing, or you have anything to add/fix, be sure to pull-request. The code was done pretty quickly, and therefore, somewhat dirty. I know and apologize, but hey - it's an open source project, so if you see something smelly - go ahead and fix it :)
Enjoy and Frag you later ;)
It is a tradition for us, to drop everything and play Quake III Arena, CTF mode, on every Thursday. Now, we did have some statistics showing each players kills etc. but we never had something to show statistics for Flags. How many did one fetched, how many did he score? did he restored any? you know... what really counts when you're playing CTF.
I looked for something on the web but couldn't find anything (if you know of any solution I'll be happy to know), so I've opened the log file and went through it to see if there is anything that might help me.
Apparently the log does mention the Flags but in such manner that it is really hard to understand in what status is the flag. You can't find anything resembling "Score" or "Fetch" but rather entries where the flag has been "touched" by a player.
To make a long story sort, I came up with a simple algorithm to resolve the Flags status, and having achieved that, the rode for creating an Angular/Node/Express (using Yeoman) application was easy.
I've uploaded that application source to Github and you can find it here:
quake-stats, an open source project
Feel free to download and use, and of course, if you feel that something is missing, or you have anything to add/fix, be sure to pull-request. The code was done pretty quickly, and therefore, somewhat dirty. I know and apologize, but hey - it's an open source project, so if you see something smelly - go ahead and fix it :)
Enjoy and Frag you later ;)
Subscribe to:
Posts (Atom)