September 25th, 2016 at 3:42 pm
I am conducting experiment on how React Single Page Apps performs with SEO. If you can think of other worth while tests for me to add, let me know.
The following site was made with react, which I’ve just submitted to google.
I implement various methods of client side content rendering.
- Home Page – Directly output HTML via react component render() function.
- About and Contact Page – Convert JSON data that’s loaded in memory to plain HTML and output it via react component render() function.
- Project Page – Consume JSON data via AJAX, Convert JSON to HTML and output via react component render() function.
- Portfolio Page – Consume JSON data via AJAX, make the AJAX endpoint extremely slow to serving content, convert JSON to HTML and output via react component render() function.
So let’s see how this turns out over the next week or so.
May 22nd, 2016 at 3:17 pm
My way, the technical lead must understand the material himself and be an effective instructor at training the rest of the team.
The popular way, the company pays for training programs for the team.
Which is the more costly approach? It’s extremely difficult to find someone who’s both an experienced developer and is an effective instructor.
May 21st, 2016 at 4:23 pm
December 15th, 2015 at 1:18 pm
December 4th, 2015 at 9:57 am
For SPF, follow this guide here. Then remember to add this to your TXT entry:
v=spf1 a mx ~all
For DKIM, follow this guide here.
Also make sure that /etc/mailname is your top level domain. (eg. make it example.com instead of something.example.com)
November 24th, 2015 at 10:06 am
Launch phase is the time leading up to launch. There are three rules to follow during the launch phase.
Rule 1 – No functionality revisions leading up to launch
Downgrade items like “Re-use the preview functionality from detail mode on list mode”.
Although an important feature to have, and relatively easy to implement, do not enhance or revise last minute or you risk breaking everything else. General rule, no functionality revision leading up to a launch.
Rule 2 – Tickets can be more than Open and Close, they can change priority
Downgrade tasks that have been partially addressed.
For example, the original task do not allow dollar signs and commas in the goal amount text field, which is a legitimate concern because it’s some people expect to enter these characters even though our system does not allow it for this field. The ticket was addressed, but a QA person discovers negative amounts weren’t being saved properly. This later realization is different (even though it’s related) from the original issue and is UNLIKELY to happen, and can be dealt with after the launch.
General rule, a task’s priority can change over time – it can start as mandatory, a temporary / partial solution can be implemented, and then it can become nice-to-have. Tick 7257 isn’t a priority anymore. So you don’t close the ticket, you simply downgrade it.
So back to general rule 1, we avoid functionality revisions leading up to launch.
Rule 3 – do-able tickets leading up to launch
Things that should be addressed leading up to launch are:
- bug fixes such as the reporting of incorrect values, and functionality that actually prevent usage
- text revisions like change 1 people donated to 1 person donated
- changing a color here and there
November 27th, 2014 at 7:33 am
When you guys look at a web software platform, can you date the style of development to a particular time period when it was popular?
Examples from my experience:
When I first saw eFront, I immediately recognized it as being identical to vTiger, SugarCRM and Moodle. So I think popular PHP architecture approach for 2005 to 2010. When I heard that eFront was upgrading its architecture to a more modern MVC style, my reaction was, “good idea, because eFront is getting more popular, and the new-age developers aren’t experienced in the old-way of development.”
When I first saw Ruby on Rails in 2011, I immediately thought of my experiences with Code Igniter. I learned later that Code Igniter’s MVC was actually inspired by Ruby on Rails, so it was the other way around. Around that time, due to RoR’s rising popularity, every framework started to copy it. So we saw massive upgrades to Zend Framework, .NET framework, CakePHP, Django etc… My reaction at the time was, “so this new way of doing MVC is really here to stay now? I guess I might as well start upgrading and organizing the Evermight tools in the same way.” So any time I see folders clearly labelled as Model, Controller, View, I reminice about the 2010-ish years. Since 2012, I haven’t seen any major MVC framework make as drastic of an architectural change as it did in 2010-ish…
When I look at the earlier Evermight projects (Startmission and earlier), I remember why I wanted to follow the .NET 3.5 approach of code behinds, which is the popular approach for most web application development between 2005 to 2010.
When I see spaghetti code from a supposedly veteren web developer, it very well could have been a popular web development approach prior to 2005 (I wasn’t a developer before this time period, so I can’t say for sure whether it is or not) given the lack of web development frameworks in those days. Or maybe they are just bad-coders.
I remember I quit my job working as a developer at University of Toronto in 2007 because I couldn’t convince the senior developers at the time of adopting modern web development practices. One example was when the senior developer’s were reluctant to adopt object oriented programming, which may seem shocking to new-age developers reading this post 2014, because they may have forgot about the poor OOP support prior to PHP 5.x. In 2007, PHP 5.x was already well received by developers who were taking advantage of more advanced OOP principles. As for the environment I was workign in, none of the senior developers believed in OOP. Some didn’t even believe in MVC (in situations where it was clear it should be used). And because ob_start() and ob_clean() was a new introduction to PHP 4, the old timers still did things like this:
echo “<html>100 lines of html code”;
echo “another 100 lines of html code with other php logic interspersed”;
repeat the above another 200 times.
In the end, I couldn’t convince anyone of anything. I demonstrated popular projects of the day like Joomla, Google Maps, Facebook that leveraged these new dev practices. My senior developers were un-moved. I thought maybe I had to de-mystify the magic behind these new technique by showing them how it’s done. So for years, I freelanced at nights and built my own projects, each project taking roughly 40 to 160 hours of development. Each project increased in complexity. The most memorable one was when I built an interactive windows-2000-like desktop with a start menu, drag-able icons, and an AJAX based text editor that saved to a database. I demonstrated these to my seniors during the day every week. I would describe their reactions as, “Oh, that’s a nice gimmick, but it won’t last.” The most senior developers in the department went as far as to argue against my work and approach on the basis that PHP wasn’t meant to support OOP, so I should stop. Or that AJAX wasn’t supported on all browser, so I should stop. Java is too heavy for web applications, that’s why web-based Java applets are dead and we have Flash, so I should stop. The list of reasons for why I should stop ran on. I ultimately did stop. I stopped working at University of Toronto. I went to Toronto Star.
I didn’t know what else I could do at U of T. I realized sometime later that there really wasn’t anything I could do to convince the senior developers of doing things the new way (new for it’s time). The senior developers have a proven approach to solving business problems in a manner that meets the business and budget requirements. They’ve done it time and time again. Their approach survived it’s time. All the latest industry practices that I was presenting were coming from me…me being the person who has yet to demonstrate how, not if, but how my approach would hold up to the challenges of constantly changing business requirements and ever decreasing budget. I emphasize how in my previous sentence because I think some senior developers were starting to understand the approach would work, especially since large companies were using it, and since I demonstrated even junior developers like me could pick it up, but they needed a seasoned individual (ie. not me) to guide them through the difficult challenges that come with doing things for the first time.
Today, I feel like I’ve become the dinosaur. Today, I run my business during the day. At night, I either run the business some more or I code. No where am I as up-to-speed on latest development trends as I once was, since I’ve diverted the majority of my attention to improving other areas of my professional game. There are developers on the team now asking me to use this design pattern, and that new framework, and this and that. And while I acknowledge many of the popular practices are proven in industry, I am reluctant to take the risks of deploying them on large scale projects without the guidance of someone who’s done it before (ie. hire expensive senior technical architect better than me). Despite all the latest and greatest tools, I just know how long it would take me to do things my-way, and I have the confidence of recovering from any disasters that result from my way of doing things. I don’t have that same confidence in my team in their ability to rebound from disasters with the new tools and new processes without my deep involvement. If I did, I would be all gung-ho about it. (More on this further down). I have full confidence in my team doing things the current way, and that’s what I’ll default to.
Although I haven’t done the greatest job at it, I try to encourage the team to stay up to date on development practices and tools by letting them exercise whatever they want on particular projects.
- asking a developer to build an event-conference tool using .NET latest technologies. But there wasn’t enough guidance from me, and the developer lost sense of priorities, and it became very stressful reaching deadline
- being the guinea pigs for the second release of PhoneGap on a rather mission-critical project, only to discover PhoneGap was still too beta to be the leading cross mobile development platform at the time, again it became very stressful to meet timelines (I experienced health issues where the whole left side of my torso broke out in shingles for a month. The project was in such bad shape that I had to delay seeing the doctor until after we completely rebuilt the project and launched, hence living with shingles for a month…felt like I was living with really bad body shots (boxing) the whole time.)
- trying to learn node.js, which changed directions to ruby on rails, and changed again to sinatra, and changed again to just ruby, while trying to automate some tests. The reasons for the constant direction change was because I was in the early stages of learning these tools, and was just pivoting towards the right tool for the job (a still incomplete journey, which I can expect a few more direction changes).
- trying out some of the latest HTML5 development tools to build really engaging and interactive video games
And there are a slew of many other examples since 2008. In doing so there were two big challenges I’d like to mention.
The first challenge was stress. Between the years 2011 and 2013, I was still very much a fan of the “latest and greatest” technologies out there. But in 2011, I was also rebuilding Evermight. The previous partnership I was in completely collapsed on my end, and I was re-starting from scratch. A big problem arose during this time because I was consulting and developing with the “latest and greatest techniques” mind set in a boot-strapped re-start-up. Everything went awry. Unexpected technical difficulties arose in every unanticipated direction (eg. the .net conference tool and hte phone gap experience). Projects almost failed if it hadn’t been for people putting their families and marriages on the line, sacrificing physical and mental health (clients first, doctors later) and incurring additional debt. Oh, and maybe throw a touch of “sorry honey, but I won’t be home for Christmas holidays” to the list.
The team’s universal mandate for corporate improvement in the coming year of 2014 was less stress. Developers said they can not sustain that level of intensity for another few years. The only reason they put up with it for so many years, where most people would have quit after two months, was because my employees were childhood friends…so I know where they live, who is most dear to them, and… you get the idea. Realizing exploitation isn’t the healthiest way to run a business, I came up with a plan to solve the problem. I have to control my fetish for the “latest and greatest”, especially on the mission critical projects. I need to give the team and company time to settle down with its existing tools and processes. I should apply something liek an 80-20 rule, where 80% of the times, we do things in a way that’s proven to work and take as little risk as possible. The other 20% of the times, we try out new tools and processes on low-priority projects that won’t hospitalize us if things go wrong.
Now that 2014 is coming to an end, i would say that we met our 2014 objective of reducing stress. No marriages were destroyed as a result of working at Evermight. Although some of us have visited our family doctors, at least no one was hospitalized for several days. And some of us decided to take vacation and celebrate things like birthdays.
Despite the success of reducing stress, a second challenge took it’s place. We were no longer advancing our technical skills the way we’ve been accustomed too. The 20% for innovation isn’t sufficient. For example, I’m leading the way with the automated tests and trying out new frameworks. But I am the least suitable person for this assignment because business operations is already more than a full time job itself. As for the other developers on the team trying out new things, the efforts are short-lived for various reasons such as self-motivation, unclear competing assignments due to lack of project management, steep learning curves, lack of clear business objectives etc… The inability for the team to sustain their innovative endeavours prevent these new tools and processes from maturing to a state where they can be used on larger and more critical projects. In the past, we solved this problem by using these new tools and processes on many mission critical projects, which forced many of us to kill ourselves to deal with all the unexpected scenarios. But without the incentive of a gun pointed at our heads, we’ve kinda just stopped.
So how do we make everyone on the team happy? How do we continue to improve our technical abilities while also avoiding the stress of 2008 to 2013? I’ve come to the conclusion that this will not happen internally. I think the solution is to hire seasoned external consultants to help us upgrade our processes. This will cost money, which I have yet to budget for. And now I feel like the guy standing at Best Buy looking at all the bright and shiny phones, contemplating whether it’s time to upgrade. My old phone which no one’s ever heard of still does everything I need it to do exceedingly well. But all the cool people have the latest phone. If I buy a new phone, it’s got to be more than just a cool factor. I need measurable differences in my day to day productivity. But new phones are coming out all the time. I can’t just buy a new phone every year. But if I don’t get the new phone, my friends will think I’m lame, and join another team. So when exactly should I buy the new phone? When exactly should I pay for the external consultant to upgrade our company?
Tough decision to make.
There are a few cards that I don’t like to play, but maybe I should. I like to say that I’ve dedicated the past 10+ years of my life to just my work. I purposely abstained myself from anything in life that doesn’t involve work. I even tried to cut out exercise (martial arts and boxing) only to realize that caused a lot of health issues that would ultimately collapse the business. So now I don’t feel as bad punching people in the face and kicking them in the ribs. If something doesn’t contribute to the business, then it must be removed from my life. If I were borrwo from religion, I would say I have sinned at times by accompanying my parents to the super market to do grocery shopping, and even worse, i enjoyed that experience. A sin because I broke the rule of doing something that has no direct benefit to the business. This mentality I have served me well between 2004 and 2010, the period when I personally experienced the most professional advancement. By 2010, it was no longer about just me. Evermight was established. The team was getting bigger, and I couldn’t do all the lifting myself. Not everyone has the same value system as me, so I can’t ask the same commitment of them since Evermight isn’t the social entrepreneurial entity I hoped it to be.
October 16th, 2014 at 12:45 pm
This will find what’s using port 80 and might even tell you the process number
netstat -lnp | grep :80
Another way to do it
lsof -i :80
September 7th, 2014 at 11:58 am
adfoajofi eoij e
September 2nd, 2014 at 7:47 pm
- Connect an ethernet cable to your computer so that you have internet access.
- Download virtualrouter from http://virtualrouter.codeplex.com onto the windows 7 computer you want to broadcast a wifi network.
- Install virtualrouter.
- Go to start menu and find Command Prompt. Then right click on Command Prompt then select Run As Administrator.
- Then type in (without quotes) “netsh wlan set hostednetwork mode=allow”. Then press enter. You can close the Command Prompt window.
- Start up Virtual Router. Give your wifi network a name, password. Then select Local Area Network. Then Start Virtual Router.
- You should now be able to see the wifi network from your other computers and devices