I just finished (and made a related presentation in my strategic management class at Boğaziçi University's Executive MBA program) Jeffrey Williams' famous book "Renewable Advantage".
Although I have some conflicts mainly about the artisian localization issue (which -according to my way of tought- is in contradiction with medieval guild structure), patent approach (described more as a defensive tool, which is -from my perspective- more likely should be considered as also an attack weapon) and some outdated examples; the concept of "economic time" (a simplified definition of the term can be the rate at which a company has to adapt to changes in the market which is examined in three main groups such as slow-cycle, standard-cycle and fast-cycle) and the journey within in the base of strategic management is worth of reading - especially if you are working in a "technology company existing in a fast economic cycle" like me.
I will provide more information about the term "economic time" in the next posts, but during this period dont miss it!
Tuesday, 31 January 2012
Tuesday, 22 June 2010
Networks Are Smart!
It's been a long time since my last post, life sometimes lead people to unexpected situations...
But now I am back for a while...
These days I am working on developing a firewall module based on netfilter/iptables. To test my module I tried to prepare a test environment containing three linux machines (both on the same local network). My test scenario is something like that:
route add -net C netmask 255.255.255.0 gw B dev eth0
And make necessary configuration on B as:
/proc/sys/net/ipv4/ip_forward
/etc/sysctl.conf -- net.ipv4.ip_forward = 1
/etc/sysconfig/network -- FORWARD_IPV4=true
Everything seems perfect but when I observe the routing of packets from A to C, I observed that after the transmission of the first packet, A detects that both A and C are on the same local network, so it bypasses B (the gateway).
I tried to find a solution by Googling but couldn't find a suitable one, so began to read documentations and found out a solution using ip masquerading. On machine B make the following configuration:
iptables -t nat -A POSTROUTING -d C -o eth0 -j MASQUERADE
And everything works as desired (each packet from A to C routed through B)
But now I am back for a while...
These days I am working on developing a firewall module based on netfilter/iptables. To test my module I tried to prepare a test environment containing three linux machines (both on the same local network). My test scenario is something like that:
- Machine A: Client machine
- Machine B: The machine where my module works
- Machine C: Server machine
route add -net C netmask 255.255.255.0 gw B dev eth0
And make necessary configuration on B as:
/proc/sys/net/ipv4/ip_forward
/etc/sysctl.conf -- net.ipv4.ip_forward = 1
/etc/sysconfig/network -- FORWARD_IPV4=true
Everything seems perfect but when I observe the routing of packets from A to C, I observed that after the transmission of the first packet, A detects that both A and C are on the same local network, so it bypasses B (the gateway).
I tried to find a solution by Googling but couldn't find a suitable one, so began to read documentations and found out a solution using ip masquerading. On machine B make the following configuration:
iptables -t nat -A POSTROUTING -d C -o eth0 -j MASQUERADE
And everything works as desired (each packet from A to C routed through B)
Tuesday, 23 March 2010
The Core Rules
I first read the following text from a blog years ago (for the writer of that blog, I am sorry I cant recall your name), and since then I always placed it where I work:
Be humble. Always first presume that you're wrong. While developers do make mistakes, and as a new hire you should certainly assist others in catching and correcting mistakes, you should try to ensure that you're certain of your observation before proudly declaring your find. It is enormously damaging to your credibility when you cry wolf.
Be discreet with constructive criticism. A developer is much more likely to be accept casual suggestions and quiet leading questions than they are if the same is emailed to the entire group. Widening the audience is more likely to yield defensiveness and retribution. The team is always considering what your motives are, and you will be called on it and exiled if you degrade the work of others for self-promotion.
The best way to earn credibility and respect is through hard work and real results. Cheap, superficial substitutes - like best practice emails sent to all, or passing comments about how great it would be to implement some silver bullet - won't yield the same effect, and are more easily neutralized.
Actions speak louder than words. Simply talking about implementing a team blog, or a wiki, or a new source control mechanism, or a new technology, is cheap. Everyone knows that you're just trying to claim ownership of the idea when someone eventually actually does the hard work of doing it, and they'll detest you for it. If you want to propose something, put some elbow grease behind it. For instance, demonstrate the foundations of a team blog, including preliminary usage guidelines, and a demonstration of all of the supporting technologies. This doesn't guarantee that the initiative will fly, and the effort might for the naught, but the team will identify that it's actual motivation and effort behind it, rather than an attempt at some easy points.
There is no one-size-fits-all advice. Not every application is a high-volume e-commerce site. Just because that's the most common best-practices subject doesn't mean that it's even remotely the best design philosophies for the group you're joining.
Be humble. Always first presume that you're wrong. While developers do make mistakes, and as a new hire you should certainly assist others in catching and correcting mistakes, you should try to ensure that you're certain of your observation before proudly declaring your find. It is enormously damaging to your credibility when you cry wolf.
Be discreet with constructive criticism. A developer is much more likely to be accept casual suggestions and quiet leading questions than they are if the same is emailed to the entire group. Widening the audience is more likely to yield defensiveness and retribution. The team is always considering what your motives are, and you will be called on it and exiled if you degrade the work of others for self-promotion.
The best way to earn credibility and respect is through hard work and real results. Cheap, superficial substitutes - like best practice emails sent to all, or passing comments about how great it would be to implement some silver bullet - won't yield the same effect, and are more easily neutralized.
Actions speak louder than words. Simply talking about implementing a team blog, or a wiki, or a new source control mechanism, or a new technology, is cheap. Everyone knows that you're just trying to claim ownership of the idea when someone eventually actually does the hard work of doing it, and they'll detest you for it. If you want to propose something, put some elbow grease behind it. For instance, demonstrate the foundations of a team blog, including preliminary usage guidelines, and a demonstration of all of the supporting technologies. This doesn't guarantee that the initiative will fly, and the effort might for the naught, but the team will identify that it's actual motivation and effort behind it, rather than an attempt at some easy points.
There is no one-size-fits-all advice. Not every application is a high-volume e-commerce site. Just because that's the most common best-practices subject doesn't mean that it's even remotely the best design philosophies for the group you're joining.
Subscribe to:
Posts (Atom)