Time for a new goal in life. Learning Haxe just for the heck of it. Looks like something interesting and worthwhile to tackle. Like I always say, you are never too old to learn more stuff.
1
Results tagged “Programming”
Just for fun, I created an example Angular application which converts a CSV file to a Material Table dynamically. Guess I was a little bored, but nonetheless it was a fun quickie break from an otherwise uneventful day.
https://github.com/kgish/angular-csv-to-material-table
Okay, so you are never too old to follow yet another dream. Time to become a future famous game developer, and this is a great way to start.
My goal is to design a truly amazing golf game which will attract droves of eager followers and in the process make me happier.
Looks like Ruby 2.7.0 has now been officially released.
There are many new improvements in this version, but here's one that I really like.
So what if I was the oldest guy there. I still learned a lot about Enterprise Angular architectures with Nx Monorepos, Strategic Design and a bunch of other interesting topics.
The younger crowd there was part of a different generation, remaining glued to their mobile phones during breaks and lunch, staring the whole time at their open laptops while the speaker gave his workshop.
As I always say and live by as well, "You're never too old to learn new stuff!"
Long live Ferris!
Any true developer worth his weight in salt has had to explore at least once and preferably many times the benefits of using the Rust Programming Language.
Decided to treat myself to a fun Angular event in December, namely the following training: Angular architectures for enterprise applications. According to the descriptionn:
"In this interactive seminar you develop a critical understanding for planning and implementing large enterprise applications with Angular. You explore and work with approaches to structure huge applications like npm packages, Nx Monorepos, and Microfrontends."
The workshop topics in which I am the most interested to learn more about are:
- Monorepos and Nx
- Micro Frontends
- I18N
You're never to old to learn new stuff, and I'm really looking forward to interacting with interesting people and further honing my Angular skills.
The NG-BE 2019 is a 2-day event in Ghent, Belgium, that brings together Angular developers and experts from all over the world to share ideas, news and opinions about Angular.
Decided to go out and splurge again, so I signed up for the following online course: Functional Programming in Haskell.
This is an even more serious training for experienced software developers, and I look forward to starting it in September.
Later on I can impress family and friends with such amazing one-liners like this:
pascal = map ([1,1]^) [0..]
which generates the infinite list of rows of Pascal's triangle (yawn).
Paying the extra €69 to get some so-called paper certificate sounds like a waste of money, but I think that it will encourage me to take things more seriously and do my best to complete the grueling course with flying colors.
Wish me luck.
In view of my upcoming assignment next month, it's time to get serious about the Ruby programming language. Although I already consider myself pretty good and gain great pleasure when coding amazing stuff with this wonderful language, an in-depth refresher from beginning to end would be useful and fun.
That's why I decided to give in and splurge, expanding my computer library collection by ordering the famous book.
This thick tome of more than seven hundred pages is the perfect medicine for me. It also looks real nice next to all my other Ruby books. I've now read about a third of this book and am sawing through it nicely with speed and agility.
Have I gone too far and lost totally my wits by purchasing this book? Now I am going to have to read it and sludge through the jungle of mathematical proofs in order to get my money's worth. Who knows if I will ever be able to understand it completely.
The other day I was looking around for a more advanced static website generator, and I happened to stumble across a wonderful tool called Middleman. Easy to install, customize, build and deploy, and the documentation is fantastic. There are even a number of template blueprints and ruby gems you can use to enhance things.
Decided my next goal in life will be to gauge my learning Haskell progress by using it to find solutions to all of the Project Euler problems.
So far so good, I completed the first one with success.
Problem 1: Multiples of 3 and 5
If we list all the natural numbers below 10 that are multiples of 3 or 5, we get 3, 5, 6 and 9. The sum of these multiples is 23.
Find the sum of all the multiples of 3 or 5 below 1000.
The very compact and elegant Haskell one-liner solution is:
sum [ x | x <- [1..999], x `mod` 3 == 0 || x `mod` 5 == 0]
There's still a long way to go...
I figured that it was high time that I finally sit down, roll up my sleeves and really figure out at a deep philosophical level what this whole functional programming languages paradigm is all about.
What better way to do this than by wrestling with the big bad bear of them all called Haskell?
So I went out and bought a book online that claims to once and for all explain clearly how it works, all the way through functors, monads, etc. I barely survived the first chapter about lambda calculus, and it's starting to get very interesting (though heavy-going at the same time). They claim that learning Haskell doesn't have to be difficult, but I've still got thirty odd chapters to go.
Haskell Programming from First Principles
Add this to the collection of all my other books about Haskell, and you could say that I'm on my way to becoming the nerdiest functional programmer around.
- Learn You a Haskell for Great Good!: A Beginner's Guide
- Developing Web Applications with Haskell and Yesod
- Learn Haskell
Eat your hearts out all you Elixirians and Clojurians.
Today I received an interesting email from someone trying to sell an online tutorial on WebdriverIO which posed the following:
"Quick question: What holds you back from writing automated tests?"
Based on my personal experience doing various projects in the wonderful world of software development, here is a list of reasons with which I replied:
- The product is already finished and in production so there's no more budget left for automated testing.
- The platform is legacy software and no one understands how it works.
- We already have an army of functional testers in India who are manually testing everything, and it's cheap.
- You need "technical" people to setup the the automated test environment, and the only technical people we have are developers and system admins.
- Developers hate to write tests and have no time to learn it.
- Most testers are high-level black-box functional testers and are not concerned with the internal details nor are technical enough to understand the underlying software.
- Setting up an automated environment is expensive.
- There are already tons of tests failing and no one gives a damn.
- The CI runs from Jenkins and the guy that set things up is no longer working for us (don't fix whats not broken).
- Managers do not fully understand what automated testing is and how it really works and are therefore unwilling to invest money.
- Automated testing means that the functionality of the complete product is known, however mostly it is undocumented or specific areas of expertise limited to certain privileged individuals.
- We're too busy and have no time.
- Good testers are hard to find, especially those that are technically inclined and/or understand how to write software.
- The product is not stable and is changing too frequently, meaning that time spent invested in writing test scripts that will continuously break is not worth it.
Signed up for the Learn Elixir and Learn Phoenix online video training.
Been procrastinating long enough so it's time to make the move and learn even more new stuff.
One of the most important credos for boosting a development team into the realm of excellence is to ensure that they can feel very proud of what they create as a coherent team. This power of creative energy mixed in with just the right amount of the fun factor is not to be under-estimated.
The speed of feedback is very important in order for the product developers to do the right job.
Developers depend on feedback in order to make the right choices at the right time.
Feedback also allows developers to realize their mistakes and incorrect assumptions early on in order to recover before it is too late.
Proper and timely feedback allows one to operate the product development process effectively, especially in a very noisy and erratic environment.
By analyzing and reacting to feedback early, one adapts efficiently to unpredictability, and one is more flexible and dynamic to ever-changing business needs.
Unfortunately, current orthodox beliefs view feedback as the evil cause of undesirable rework loops, stubbornly insisting that rework is to be avoided by designing things right the first time (as if this is ever possible).
Of course we all know how foolish such an unfounded belief is, history has shown us too many failed projects which have fallen victim to this stubborn way of thinking.
Feedback gives one new and valuable information that can be used to freshen our viewpoints and make better economic choices.
There's an illusion going on out there, and it's best to avoid it with all your might. Just because you are in a hurry and think it's expedient to throw important requests over the wall into the development team as quickly as possible, does NOT mean that you are following the shortage route to getting it done. Done, done. Not done by development, not done by testing and not done as in "delivered" to the customer and curing his headache. That's really the moment of truth when the customer benefits from all that effort (money spent), when profits start rolling in. Repeat, does NOT. Too many people fail to understand this simple concept, because they are blinded by the glitter of money (so-called) and the individual bonus. In truth, injecting random tasks without proper preparation will in the end take much longer to actually get to the happy customer. Think about best practices. Follow the rules of thumb, and you will avoid being consumed later by the nightmare of endless after care and all night bug-fixing marathons (which will eat up any short term profits in no time). Here is what you should do with these request first. Analyse and localize, provide a structured and high-level description, prioritize, and then wait. Waiting is the hardest thing to do, especially in a commercial world where we the greedy ones are pressured to make a quick buck, or else. Or else the competitors will jump in front of you at your slightest hesitation. No, be wise and wait until the last possible moment, wait through that incubation period until the time is ripe. Decide when you are just still in control, just at furthest point within the window of opportunity, right before the moment that the decision will be forced upon you.
I couldn't resist the great book offer that the kind folks at O'Reilly emailed me, so I splurged and purchased the e-book called RESTful Rails Development by Silvia Puglisi.
Although I may fool myself into believing that I am some kind of expert and this is already all very familiar material, it's always good to refresh one's mind. Perhaps even discovering new information or coming across eye-opening code snippets. Rails, REST and Ruby, yeah sure I already know all that stuff. Or do I?
Coding years on end without keeping track of new stuff can be compared to driving a car your whole life and thinking that you are perfectly competent when actually you have unknowingly become a bigger danger on the road than you realize.
Be careful before you accidentally kill your fellow developer who is pair-programming next to you. Like I always say (sorry if I keep repeating myself too much), I am never too old to learn new stuff.
The book is still the early release raw and unedited, but I still found that there were way too many errors and typos. Sure the price was right and I should not have high expectations, but when you get into the flow of reading and are regularly disrupted by unclear and misspelled words, it's a bit of a hassle.
Especially when code fragments are wrong, I hate it when there are code typos. You never know if that is how it's really supposed to be or if it is an error, until you fire up irb or vi, type it all in yourself and (if there are no syntax errors) running it.
For example, seeing '{ :product_id => 2 }' all over the place instead of '{ :product_id => 2 }', now that's pretty aggravating.
Although the English isn't fluent, the contents and descriptions are done quite well and the story-line is very complete. I just hope that in the coming newer releases that the errors will be fixed and the sentences made to flow better.
In Elixir, the pipe operator '|>' takes the output of the expression on the left of it, and feeds it in as the first argument to the function on the right of it.
You can even tag on additional functions together in an endless chain to form a pipeline of functions to be called, very similar to the Unix method of piping command utilities together, e.g. 'ps ax|grep vim|awk '{ print $1 }'.
In other words, the following statement using the pipe operator |> :
f( a ) |> g( b ) |> h( c )
is equivalent to:
h( g( f( a ), b ), c )
This can be extended to include functions with multiple parameters like this:
f( a, b ) |> g( c, d )
being equivalent to:
g( f( a, b ), c, d )
See if you can figure out what the following does:
-5 |> abs |> Integer.to_string |> IO.puts
Here's a small hint to help you along:
IO.puts(Integer.to_string(abs(-5)))
Here are some references in which you might be interested:
No I didn't forget. The answer is 5 of course.
Recent Comments
- Charles
- jpmcfarlane
- Kiffin
- jpmcfarlane
- KathleenC