Wednesday, April 20, 2011

When to override GetHashCode()?

When we should override the GetHashCode() method provided by 'Object' class in 'System' namespace.

From stackoverflow
  • When you override Equals, basically. When you want to provide a different idea of equality than simple reference equality.

    String is a good example of this - two strings are equal (under a simple Equals call) if they represent the same sequence of characters. The hash code reflects this, such that if two strings are equal they will have the same hash code. (The reverse isn't necessarily true - two unequal strings can have the same hash code, but it's unlikely.)

    (Strings are tricky in other ways, mind you - there are lots of different ideas of equality based on culture and casing, but String.Equals just looks at the UTF-16 code points which make up the string, and compares them in the simplest conceivable fashion.)

    RSolberg : My coworker and I were just discussing this one today. Makes much more sense now. Thanks Jon.
    tush1r : thanks to John for such easy to understand description.
  • If you override Equals you must override GetHashCode as well.

  • "The GetHashCode method can be overridden by a derived type. Value types must override this method to provide a hash function that is appropriate for that type and to provide a useful distribution in a hash table. For best results, the hash code must be based on the value of an instance field or property instead of a static field or property.

    Objects used as a key in a Hashtable object must also override the GetHashCode method because those objects must generate their own hash code. If an object used as a key does not provide a useful implementation of GetHashCode, you can specify a hash code provider when the Hashtable object is constructed. Prior to the .NET Framework version 2.0, the hash code provider was based on the System.Collections..::.IHashCodeProvider interface. Starting with version 2.0, the hash code provider is based on the System.Collections..::.IEqualityComparer interface."

    http://msdn.microsoft.com/en-us/library/system.object.gethashcode.aspx

  • If your type should follow value semantics (comparing contents) instead of reference semantics (comparing object identity) , you should write you own override of instance object.Equals().

Mysql stored procedure : cant run from PHP code

I have below stored procedure to check the user name availability

DELIMITER $$;

DROP PROCEDURE IF EXISTS tv_check_email$$

CREATE PROCEDURE tv_check_email (IN username varchar(50)) BEGIN select USER_ID from tv_user_master where EMAIL=username; END$$

DELIMITER ;$$

when i run this from my mysql front end tool, it is working fine

call tv_check_email('shyju@techies.com')

But when trying to execute from the PHP page, i am getting an error like "PROCEDURE mydatabase.tv_check_email can't return a result set in the given context"

Can any one tell me why it is so ?

I am sure that my PHP version is 5.2.6

Thanks in advance

From stackoverflow
  • You need to bind your result into an OUT parameter.

    See the mysql docs on stored procedures

    mysql> delimiter //
    
    mysql> CREATE PROCEDURE simpleproc (OUT param1 INT)
        -> BEGIN
        ->   SELECT COUNT(*) INTO param1 FROM t;
        -> END;
        -> //
    Query OK, 0 rows affected (0.00 sec)
    
    mysql> delimiter ;
    
    mysql> CALL simpleproc(@a);
    Query OK, 0 rows affected (0.00 sec)
    
    mysql> SELECT @a;
    +------+
    | @a   |
    +------+
    | 3    |
    

    +------+

    Shyju : thanks cody , it worked
  • It looks like if you use the mysqli PHP library you can actually retrieve your result set without having to use an OUT variable and another query to retrieve your value. This article covers the details:

    http://amountaintop.com/php-5-and-mysql-5-stored-procedures-error-and-solution-qcodo

  • Cody is not 100% right. You can bind your resulting return columns and return select data from within a stored procedure.

    $mysqli = new mysqli("localhost", "my_user", "my_password", "world");
    
    $stmt = $mysqli->prepare("call tv_check_email(?)");
    $stmt->bind_param('s', "shyju@techies.com");
    $stmt->execute();
    
    $stmt->bind_result($userid);
    
    while ($stmt->fetch()) {
      printf("User ID: %d\n", $userid);
    }
    
    $stmt->close();
    $mysqli->close();
    
    Cody Caughlan : Ah yes, much better. From my understanding, the std. mysql extension doesnt support accessing result sets w/o OUT, but the mysqli does (as your code indicates)? Good to know.

What are the technological limits to the usability of AJAX web apps?

I am trying to understand the technical limits to the usability of web-based productivity applications that use only open, cross-platform technologies such as Javascript, HTML, and CSS on the client. [1]

Let's assume for a moment that in the next few years the capabilities of web browsers continue to improve (e.g. with HTML 5 and faster JS engines), and significant progress is made in increasing bandwidth and reducing latency. What technological barriers (e.g. performance, graphics, modes of user interaction) will remain that limit the usability of web productivity apps when compared to conventional client-side applications? (Apart from offline access and issues that have significant non-technological aspects, such as privacy concerns.)

[1] By "productivity applications", I mean things like office suites, email, calendars, and diagramming programs.

From stackoverflow
  • Older browsers. There are still a lot of IE 6 users around. As the web becomes more AJAX-y, current browsers that just barely cut it are going to be more of a problem.

    Funka : I've never ran into any significant problems with Ajax on IE6, especially when using a framework for abstraction, such as jquery (Don't get me started on the CSS problems, though!)
  • and significant progress is made in increasing bandwidth and reducing latency.

    This IS the limitation, and latency is not something that is going to improve significantly in the future (there are real physical limits here). The roundtrip is the bottleneck.

    As for improvements, I see as javascript getting faster there being less AJAX and more client-side work. Right now, alot of AJAX is used to get display HTML form the server for rendering in the browser. In the future, AJAX will be used strictly for data, with javascript handing all the display.

    SO the barrier I see is javascript performance.

    Calvin : That really depends on where you live. If you live in Japan or South Korea where they're already rolling out 1Gbps symmetric FttH connections, then _maybe_ you can make that claim. But here in the U.S., the majority of the population still only has access to 13-year-old ADSL technology.
  • The real issue is that html+css does not provide 2d or 3d rendering primitives or any sort of real-time sound interface. Without those, a lot of the stuff we expect out of desktop apps aren't possible. I'm thinking of games, 2d/3d image and video editting, real time communications, that sort of thing. Obviously, you can do these things now, just not with open standards. With a little luck, more and more of the rich functionality available with Flash, Silverlight, and JavaFX will get pushed into "standards" and the barriers will be completely gone.

    I don't see any reason 99% of "productivity" apps couldn't run in a browser in a few years.

  • Basically with the flash virtual machine and javascript implementations in browsers improving, what you are seeing is convergence of traditional web functionality with typical client side application design. The primary difference is that the code for each page or snippet is downloaded and executed on demand and within a standardised environment across the various platforms out there. Essentially traditional web applications are becoming more like client applications. However there is still a need for web applications that don't operate like this. Today, you have the choice of either, or a combination of both.

Has anyone used Data Dynamics Reports?

We currently use ActiveReports (by Data Dynamics, now Grape City) for canned reports, but are considering moving up to their Reports package. If you've used it, I'd love to hear your take on:

  • Performance - do you feel it will scale well for a web based app (particularly compared with ActiveReports)
  • Export to Excel - it appears to provide a much cleaner export to Excel (ActiveReports' Excel export is awful, our biggest reason for considering a switch)
  • Other pros/cons (my company is pretty small, the $3,000 for 2 licenses is a lot for us)

Thanks for your feedback!

From stackoverflow
  • I've only used ActiveReports as well, but their web licensing model is a bit expensive in general in my view, espeically if you need to develop multiple apps on multiple servers. Then there is the per developer costs as well.

    I use DevXpress XtraReports and have been fairly happy with it so far and it has some fairly decent export functionality and a much better licensing model.

    Regarding export to Excel, I've not seen any reporting tool do it well, mainly due to the formatting issues with the report itself. What we typically do is provide the formatted report to the user, along with an additional link for an Excel export which is a similar but different query with the raw data the report uses.

    Another option over formatted printable reports is using grids such as Infragistics which allow you to do sorting, grouping, summaries, and which has excellent Excel export features.

  • Here are some additional information for you to consider about ActiveReports & Data Dynamics Reports:

    ActiveReports Licensing:

    There license is per developer. There are no royalties. You can write as many applications as you want and deploy your application to as many users or as many servers as you want without any additional costs. Read the ActiveReports License agreement here.

    Reporting to Excel:

    First of all, schooner is absolutely correct that all the other reporting tools have a poor scenario when exporting to excel. We recognized the same after many years of experience with ActiveReports. Frankly, it is a very hard problem to take reports designed to be paginated or deployed on the web and put them into a cell-based layout of a spreadsheet.

    However, with Data Dynamics Reports', we took a completely different approach. Instead of creating just another "export to Excel", where we look at "paginated" report output and try to fit it into a spreadsheet somehow, we generate the excel output based on two things: A template and the actual data in the report. By using a template, which is actually a specially formatted excel sheet (cells have some special place holders in them) the reporting engine can output the report's content to an excel sheet completely independent of how the report is laid out when paginated. We call this concept a "Transformation Extension" for Excel since it takes the report's content and transforms it to excel based on a template.

    By default DDReports will generate a default template that you will find more often than not has pretty good output. However, if the excel output is not what you want, you can instruct DDReports to save the template so you can customize the output in excel.

    The best way to get an introduction to this is to watch the screencast for the Excel Transformation Extension in Data Dynamics Reports here. Jump to about 1:20 in the screencast if you impatient and see an example of a simple template. Keep in mind this is a very simple template and the possibilities are much more sophisticated. Unfortunately, thus far we haven't published very good documentation on using the excel transformation extension template syntax yet, but let me know if you have questions and I'll help you out! Just comment on this post or send an email to our support team.

    Scott Willeke

    Data Dynamics / GrapeCity

    Jess : Hey Scott, thanks a ton for your reply! We definitely like the Excel output features of DDReports ... but will DDReports have similar high volume performance to ActiveReports? We'll be running a few hundred thousand reports per week off of a single server ... thanks!
    scott : Yes, DD Reports' is designed for high volume loads, especially on the server. However, the engine in DDR and AR are different so each engine will have different performance behaviors under different reports, but on the server I think you'll find DDRs performance good. If not, let me know.
  • We use both products and they are quite different from each other. I have been a long time user of Active Reports and have loved them. But when it came time to select a .net reporting tool we did not want to spend a bunch of $$ so we decised to get their DDR product. It took me a couple of weeks to get used to it as I kept trying to use it like Active Reports. Not a good idea. Anyways, once you get used to it it does a decent job. there are some things that they need to do to improve the product. Here are the things that stand out.

    1. You cannot access the control collection in the code area. This is a huge problem if you want to change anything like data binding inside the report.

    2. The database connection have to be refreshed if you repopen the report int he designer. This took a while to figure out and we wondered why our fields would not show up in the preview mode when re reloaded the report.

    3. Their new tech support is terrable. They were bought out recently and now when you call tech supprt you get someone tht has no knowledge that always tells you that someone will call you back. 80% of the time you get no call back. The otehr 20% of the time you get a sample emaild to you that has nothing to do with your issue. Now this is accorss the board with both products. THey used to have great tech support. I hope they fix this.

    Those are the main problems and I know they are workign to solve the issues. Like i said we use boh DDR and Active Reports. If you need to do complicated reports stick with Active Reports. If they are simple and you do not want to spend a lto fo money then DDR works fine. I see DDR getting better with each release but it will take a while to get the knks worked out.

    Just my opinion

  • This is to give more information to Bill's response in this thread. I tried to post a comment, but ran out of room :)

    Bill Thanks for your honest assessment. Let me give some comments for you from the inside on the issues you mentioned:

    1: Admittedly it is not quite as intuitive to access the controls collection as it was with AR, but you /can/ do it. You need to do it outside of the report (not in the script/code embedded into the report). To do it you can load the rdlx file in a ReportDefinition object. For example:

    var rpt = new DataDynamics.Reports.ReportDefinition(new FileInfo("myfile...rdlx"));
    var list = (DataDynamics.Reports.ReportObjectModel.List)rpt.Report.Body.ReportItems["myList"];
    var txt = (DataDynamics.Reports.ReportObjectModel.TextBox)list.ReportItems["myTextBox"];
    txt.Value = "=Fields!MyField.Value";
    

    However, depending on the scenario you're after there may be a better way to handle this than changing the binding on the control/reportItem itself. It is difficult to say more without knowing more about your particular scenario/goals.

    2: There was recently some discussion I was involved in on how to improve this in the very near future. The dev team was gathering use cases and doing some investigation on various caching strategies to keep hitting the database to an absolutely minimum in the designer. So look for improvements in this area in an upcoming build.

    3: Unfortunately, we're working through some challenges with our new technical support team. However, we are improving constantly and we're working hard to bring up the new guys as quickly as possible. If you have a problem with one of your incidents with support feel free to email me personally with your case number and I'll work to try get your case escalated or help out in any way I can (scott dot willeke at grapecity dot com).

    Thanks again for your feedback, my next letter is an internal one based on your feedback to help us improve!

    Scott Willeke
    Program Manager
    Data Dynamics / GrapeCity inc.
    

What is the best compression algorithm for small 4kb files?

I am trying to compress TCP packets each one of about 4kb in size. The packets can contain any byte (from 0 to 255). All of the benchmarks on compression algorithms that I found were based on larger files. I did not find anything that compares the compression ratio of different algorithms on small files, which is what I need. I need it to be open source so it can be implemented on C++, so no RAR for example. What algorithm would you recommend for small files of about 4 kilobytes in size? lzma? hacc? zip? gzip2?

From stackoverflow
  • All of those algorithms are reasonable to try. As you say, they aren't optimized for tiny files, but your next step is to simply try them. It will likely take only 10 minutes to test-compress some typical packets and see what sizes result. (Try different compress flags too). From the resulting files you can likely pick out which tool works best.

    The candidates you listed are all good first tries. You might also try bzip2.

    Sometimes simple "try them all" is a good solution when the tests are easy to do.. thinking too much sometimes slow you down.

    Blorgbeard : I agree, and ask that you post your results when you're done :)
  • For small packets biggest difference is achieved by Huffman-like distribution encodings since most used byte values automatically consume the least space. If you apply a dictionary based compression (LZ variants) on top of it you would have a very decent compression running.

  • I don't think the file size matters - if I remember correctly, the LZW in GIF resets its dictionary every 4K.

  • ZLIB should be fine. It is used in MCCP.

    However, if you really need good compression, I would do an analysis of common patterns and include a dictionary of them in the client, which can yield even higher levels of compression.

  • I did what Arno Setagaya suggested in his answer: made some sample tests and compared the results.

    The compression tests were done using 5 files, each of them 4096 bytes in size. Each byte inside of these 5 files was generated randomly.

    IMPORTANT: In real life, the data would not likely be all random, but would tend to have quiet a bit of repeating bytes. Thus in real life application the compression would tend to be a bit better then the following results.

    NOTE: Each of the 5 files was compressed by itself (i.e. not together with the other 4 files, which would result in better compression). In the following results I just use the sum of the size of the 5 files together for simplicity.

    I included RAR just for comparison reasons, even though it is not open source.

    Results: (from best to worst)

    LZOP: 20775 / 20480 * 100 = 101.44% of original size

    RAR : 20825 / 20480 * 100 = 101.68% of original size

    LZMA: 20827 / 20480 * 100 = 101.69% of original size

    ZIP : 21020 / 20480 * 100 = 102.64% of original size

    BZIP: 22899 / 20480 * 100 = 111.81% of original size

    Conclusion: To my surprise ALL of the tested algorithms produced a larger size then the originals!!! I guess they are only good for compressing larger files, or files that have a lot of repeating bytes (not random data like the above). Thus I will not be using any type of compression on my TCP packets. Maybe this information will be useful to others who consider compressing small pieces of data.

    EDIT: I forgot to mention that I used default options (flags) for each of the algorithms.

    kquinn : Your test is pretty worthless. Just about *any* compression algorithm will choke on random data -- in fact, compression ratio is a useful test for *how random* a chunk of data is -- if "compressing" enlarges data, it's probably high-entropy. Try again with real data and you might get useful results.
    Rick C. Petty : I agree that the test is worthless. Randomly-distributed data will not compress, in fact the basis of most compression algorithms is that the data is not random. Also, your comparison does not include zlib which only adds 5 bytes every 64k when STORE is used instead of DEFLATE.
    derobert : Compression is not magic. It works by observing repeating patterns. Random data has no repeating patterns, and will thus not compress. It can not, as 8^4096 > 8^4095.
  • I've had luck using zlib compression libraries directly and not using any file containers. ZIP, RAR, have overhead to store things like filenames. I've seen compression this way yield positive results (compression less than original size) for packets down to 200 bytes.

  • Here are some questions to ponder!!!

    Are you transmitting the dictionary within each packet?

    How big is the dictionary for each file?

    Is the data really random?

    I would suggest you analyze your data and build a static dictionary that the receiving 'knows' or at least can be updated occassionally.

    This will save considerable space and transmission time. There is no reason why this dictionary can't be huge compared to you packet size of 4K. ie 32MB.

    What's the best way to transfer the contents of the phone book from A to B? Tell B to pick his copy and use it!!!

  • Choose the algorithm that is the quickest, since you probably care about doing this in real time. Generally for smaller blocks of data, the algorithms compress about the same (give or take a few bytes) mostly because the algorithms need to transmit the dictionary or Huffman trees in addition to the payload.

    I highly recommend Deflate (used by zlib and Zip) for a number of reasons. The algorithm is quite fast, well tested, BSD licensed, and is the only compression required to be supported by Zip (as per the infozip Appnote). Aside from the basics, when it determines that the compression is larger than the decompressed size, there's a STORE mode which only adds 5 bytes for every block of data (max block is 64k bytes). Aside from the STORE mode, Deflate supports two different types of Huffman tables (or dictionaries): dynamic and fixed. A dynamic table means the Huffman tree is transmitted as part of the compressed data and is the most flexible (for varying types of nonrandom data). The advantage of a fixed table is that the table is known by all decoders and thus doesn't need to be contained in the compressed stream. The decompression (or Inflate) code is relatively easy. I've written both Java and Javascript versions based directly off of zlib and they perform rather well.

    The other compression algorithms mentioned have their merits. I prefer Deflate because of its runtime performance on both the compression step and particularly in decompression step.

    A point of clarification: Zip is not a compression type, it is a container. For doing packet compression, I would bypass Zip and just use the deflate/inflate APIs provided by zlib.

  • You can try delta compression(http://en.wikipedia.org/wiki/Delta_encoding). Compression will depend on your data. If you have any encapsulation on the payload, then you can compress the headers.

  • If you want to "compress TCP packets", you might consider using a RFC standard technique.

    • RFC2394 IP Payload Compression Using DEFLATE
    • RFC2395 IP Payload Compression Using LZS
    • RFC3173 IP Payload Compression Protocol (IPComp)
    • RFC3051 IP Payload Compression Using ITU-T V.44 Packet Method
    • RFC5172 Negotiation for IPv6 Datagram Compression Using IPv6 Control Protocol
    • RFC5112 The Presence-Specific Static Dictionary for Signaling Compression (Sigcomp)
    • RFC3284 The VCDIFF Generic Differencing and Compression Data Format
    • RFC2118 Microsoft Point-To-Point Compression (MPPC) Protocol

    There are probably other relevant RFCs I've overlooked.

troublesome javascript

I'm trying to make a little tag list doohickey for adding and removing tags. I have a textbox where the user can enter the tags, separated by commas. and an add button. I would like it for when the user clicks the add button to add a small div to the inside of a div below the box. the small div should contain the tag and a little x for which to remove the tag later. heres what I have:

<script type='text/javascript'>
  function tagsremove(tag) {
    document.getElementByName('tags').value.replace('/'+tag+'\,\s/', '');
  }

  $('#tagbutton').click(function(){
    var tags = $('#tagsbox').text().split(", ");
    for (var tag in tags) {
      document.getElementByName('tags').value += tag +", ";
      $('#curtags').append("<div class='tag'>" 
        + tag 
        + " <a href='#' onlclick='tagsremove(\'" 
        + tag 
        + "\');$(this).hide();'>x</a></div>")
    }
  });
</script>

<div class='statbox'>
  <form method='post' action='post.php' id='writeform'>
    <p class='subtitle'>Title</p>
    <input type='text' name='title' id='titlebox' /><br />
    <p class='subtitle'>Body</p>
    <textarea id='postbox' name='body' rows='10'></textarea><br />
    <p class='subtitle'>Tags</p>
    <input type='text' id='tagsbox' /><input type='button' id='tagbutton' 
      value='Add' />
    <p class='subsubtitle'>Seperate by commas 
      (eg. "programming, work, job")</p>
    <div class='subsubtitle' id='curtags'>Current Tags:</div>
    <input type='hidden' value='' name='tags' />
  </form>
</div>

The problem i'm having is that when I click the add button, nothing happens. I would like to fix this.

From stackoverflow
  • I am not familiar with using this method to call a function when a button is clicked

    $('#tagbutton').click(function(){
    

    I usually just put

    onClick='function()'
    

    inside the input tag. and declare the function as normal up in the script.

    Also, I think you should delimit tags with a single space. this is what people are used to. but if you do decide you want to be able to use multiple word tags, then delimit by "," not ", "

    Alconja : Looks like he's using jQuery.
    I.devries : Javascript shouldn't be in your HTML. Behaviour should be seperated from markup.
  • My guess is your script block that registers the click event is being executed before the dom is loaded, so the click event isn't actually being registered to a real element. Put your click event inside the document.ready event like this:

    $(function() {
        $('#tagbutton').click(function(){
            //etc...
        });
    });
    

    Also, (as an aside) why are mixing jQuery with regular javascript? It would probably be neater to change your hidden tags field to have an id of tags & do $('#tags').val(...) rather than document.getElementByName('tags').value = ...

    Charlino : Exactly, doesn't exist when the $('#tagbutton').click() is called.
  • Your first problem is that

    $('#tagsbox').text()
    

    should be

    $('#tagsbox').val()
    

    because #tagsbox is an input field.

    There are other issues, like splitting on "," and then trimming rather than splitting on ", " but I think your main problem is the .text() vs .val()

  • You have some issues in your code:

    1 ) document.getElementByName('tags')

    That such function doesn't exists, the function you're trying to use is getElementsByName (notice the 's'), but since you're using jQuery, you could use a selector like:

     var hiddenTags = $('input[name=tags]');
    

    2) You're using text(), instead val() as @Blair point's out

    3) In the foreach, you access the element indexes only, to access the actual element value, you have to do something like this:

    for (var i in tags) {
        var tag = tags[i];
    }
    

    There will be more work to do, but for start, check my corrections here.

  • First, as someone above mentioned, your Javascript code for the onclick event is being registered before the element is created on the page. Thus, it is not bound. To fix this, use, wrap your code in this dom ready function provided by jQuery.

    $(document).ready(function () {
        //put code here
    });
    

    Change this line var tags = $('#tagsbox').text().split(", ") to

    var tags = $('#tagsbox').attr('value').split(',')
    

    There is also a syntax error in your code since document.getElementByName is not a JS function. Perhaps assign it an id or a name attribute to target it.

    Next, once you get the hidden tags split into an array, perhaps traverse them this way to build them.

    $.each(tags, function(i, val) {
        $('#curtags').append("<div class='tag'>" 
        + val 
        + " <a href='#' onlclick='tagsremove(\'" 
        + tag 
        + "\');$(this).hide();'>x</a></div>")
    });
    

Fogbugz or BaseCamp which proj man. tool do you prefer

Which do you prefer Fogbugz or Basecamp (project management tools).

We are trying to decide which one to go ahead with so any likes and dislikes and things to watch out for would be appreciated.

From stackoverflow
  • I have only used Fogbugz for bug tracking as well as development tasks. I like creating creating case out of a bug, integration with perforce. The whole UI experience is very user freindly.

  • If you're dealing with a single outside client for the project use Basecamp. It's designed for facilitating that type of communication and it does so very well. But it's not really ideal for a software project. You can't assign items to people, there's no scheduling, etc. Using it to manage a software project would definitely be a classic square peg/round hole situation.

    If you're working on the project only internally with a team, FogBugz hands down. Evidence-based scheduling is brilliant. It has proper task tracking (priorities, due dates, user assignments, etc) and source control integration. It was built for managing a software project and it excels at it.

  • I haven't had any experience with Basecamp (have been looking at it, but no actual usage), but I can say that I really do like Fogbugz.

    What I like about it is its ease of use, no-nonsense approach to things, and its simplicity. Also, since you get the full documentation for the database backend (on MS SQL Server or MySQL), it's open for your own extensions.

    I give Fogbugz a big THUMBS UP

    Marc