Saturday, September 21, 2013

Gravity Always Wins

It's very common that when CRT monitor is being rotated (turning to portrait mode) while it is turned on it becomes discolorized, the color tends to go back to normal after a few minutes. So when rotating a CRT monitor, it's better to turn it off first. The components of a CRT monitor which are very heavy, tend to be stressed when rotating the CRT monitor, the stressing effect is more pronounced when you are rotating the CRT monitor while it's turned on.


That discoloration doesn't happen on modern LCDs, so it's surprising when a colleague is rotating his LCD monitor, the screen color is turning yellowish. There got to be an explanation for the discoloration, and why most often it's yellowish, why not some color like fuschia? :p


I have a pivot-capable LCD monitor at home, but there's no discoloration happening even I'm rotating the LCD while the power is on.


So what's the difference between the LCD at home and office? The LCD in our office happens to use VGA cable instead of HDMI or DVI. VGA cables tend to loosen when not screwed tightly. And those pins in VGA cable has their own color task. Those pins carries signals for colors. For the illustration:



So that's the explanation for the yellow. When rotating a VGA cable-equipped LCD monitor, the VGA cable is loosening a bit, the RED and GREEN pin still sticks, while the BLUE is loosening a bit when the VGA cable is being oriented vertically. RED + GREEN === YELLOW, that's for 90 degree. When rotating to 180 degree the screen discolorized to CYAN, i.e., the RED loosens, leaving the display with just two color signals instead, GREEN and BLUE, which when combined becomes CYAN.

As for why discoloration doesn't happen on HDMI and DVI for that matter, both cables are not analog, i.e. they don't carry signals, what they carries are data instead. So there's no such thing on an HDMI-equipped LCD for a BLUE pin that loosens while rotating it.



Happy Coding! ツ

Monday, September 9, 2013

SQL Server Said, PostgreSQL Said. APPLY and LATERAL

SQL Server CROSS APPLY:
select m.*, elder.*
from Member m
cross apply
(
    select top 1 ElderBirthDate = x.BirthDate
    from Member x 
    where x.BirthDate < m.BirthDate 
    order by x.BirthDate desc
) as elder
order by m.BirthDate
Equivalent on PostgreSQL:
select m.*, elder.*
from Member m
join lateral 
(
    select x.BirthDate as ElderBirthDate, x.FirstName as ElderFirstName
    from Member x 
    where x.BirthDate < m.BirthDate 
    order by x.BirthDate desc
 limit 1
) as elder on true -- Though PostgreSQL's LATERAL offers more flexibility than SQL Server's APPLY, I haven't yet found a use case to use a condition on LATERAL, hence the hardcoded true
order by m.BirthDate
Note, a JOIN LATERAL(explicitly INNER JOIN LATERAL) with a condition of always true, is essentially a cross join. We can rewrite the PostgreSQL code above as follows:
select m.*, elder.*
from Member m
cross join lateral 
(
    select x.BirthDate as ElderBirthDate, x.FirstName as ElderFirstName
    from Member x 
    where x.BirthDate < m.BirthDate 
    order by x.BirthDate desc
    limit 1
) as elder -- we don't need to put any condition here anymore since this is a cross join
order by m.BirthDate
SQL Server OUTER APPLY:
select m.*, elder.*
from Member m
outer apply
(
    select top 1 ElderBirthDate = x.BirthDate, ElderFirstname = x.Firstname
    from Member x 
    where x.BirthDate < m.BirthDate 
    order by x.BirthDate desc
) as elder
order by m.BirthDate
Equivalent on PostgreSQL:
select m.*, elder.*
from Member m
left join lateral 
(
    select x.BirthDate as ElderBirthDate, x.FirstName as ElderFirstName
    from Member x 
    where x.BirthDate < m.BirthDate 
    order by x.BirthDate desc
    limit 1
) as elder on true -- Though PostgreSQL's LATERAL offers more flexibility than SQL Server's APPLY, I haven't yet found a use case to use a condition on LATERAL, hence the hardcoded true
order by m.BirthDate

Related: http://www.ienablemuch.com/2012/04/outer-apply-walkthrough.html

Example: http://www.sqlfiddle.com/#!17/50ee1/8

Happy Coding! ツ

Monday, September 2, 2013

Yes please, pass the smart data structure

“Smart data structures and dumb code works a lot better than the other way around” -- http://stackoverflow.com/questions/2953867/example-of-eric-raymonds-smart-data-structures-principle



“If the data structures are quality tools, they will make the rest of the code easier and cheaper to write. By having high quality data structures, you reduce the effort required for the rest of the code.” -- http://stackoverflow.com/questions/2953867/example-of-eric-raymonds-smart-data-structures-principle



“Show me your code and conceal your data structures, and I shall continue to be mystified. Show me your data structures, and I won’t usually need your code; it’ll be obvious.” -- http://blog.mongolab.com/2012/08/why-is-mongodb-wildly-popular/



“Bad programmers worry about the code. Good programmers worry about data structures and their relationships.” -- http://programmers.stackexchange.com/questions/163185/torvalds-quote-about-good-programmer



Don’t fell in love with code so much. Love smart and intuitive data structure instead, achieving that, the code almost writes itself. The smarter the data structure one have, the lesser the code one needs to write.



For example, if you have the following bar chart:



If you are passing the ordinal (this.x) of the clicked bar chart to the service, i.e. Goals = 0, Self-Assessment = 1, Review = 2, etc., your code need to interpret on the service layer what was clicked by the user. And what's more annoying is if there are some gaps in the chart, say the chart can be customized, the Self-Assessment is not present on the chart, the rest of the bar charts need to have their ordinal be adjusted too. Goals = 0, Review = 1, Objective = 2, etc. So on the service layer, the code should not blindly interpret that 1 is equal to Self-Assessment, as 1 is now a Review.


If the data being passed to service is not smart, the code on the service need to re-interpret the meaning of the data being passed to it, the code on the service need to be very smart, this makes the code very brittle when there are regular changes on the app.


We should make the data smarter, it would result to lesser code, small and straightforward code is easier to read and debug. One way to make the value being passed from bar chart to service smarter is to generate a corresponding array when the bar charts are generated. So instead of passing the ordinal...


events: {
    click : function() {
                  
        
        // pass the ordinal value this.x to service layer via ajax
        
    }
}


...do this instead:
var sections = ['G','S','R','O','F']; // dynamically-generated

.
.
.

events: {
    click : function() {
                  
   
        var section = sections[this.x]; // use a smarter data structure, use something that has a semantics upfront

        // pass the section value to service layer via ajax
        
    }
}


Accomplishing that, the code on the service layer won't have a need to re-interpret the meaning of the value being passed to it. Call the usage of smarter data structure a domain-driven development if you will, a dumb data structure such as ordinal doesn't carry any semantics, the quality of the code will suffer consequently.





Happy Coding! ツ