I had been programming in Python and C/C++,C# for more than 5 years and one question that I always ask to myself before is, when is the right time to use a dynamically typed language such as Python and a strongly typed language as C/C++,C#?
Recently, I had been assigned as lead a team for a big project. I chose C# as the language. And after the development was finished, we produced many lines of codes and lots of source files (150+ .cs files) with some third party libraries. These are the things that I learned from that experience:
1.The compiler check provides great help in big projects with lots of source file and with many developers.
2. It is much better to see the error on compile time rather than on run time.
3. We are refactoring aggressively. The compiler helped us a lot to see if we broke something.
4. The compiler check also protects our unit tests (sometimes the developer forgets to update the unit test after refactoring)
5. There was one time that the third party library manufacturer issued an update, and they changed the enum structure. Luckily, the compiler catched that one!
In case if I chose Python on that project, I may have been scratching my head everytime there are run-time errors which could have been easily catched by the compiler and I may need to double or triple my effort to have a very strong unit test suite to compensate for the lack of compile-time check.
Am I saying that I will not use Python anymore? No, I will never stop using python and I still love python. I am using python for numpy/scipy prototyping, build script, raspberry pi experimentation ,testing and some projects that don't require lots of classes and logics. Although I will always consider first the potential size of the project before using a dynamically typed language as I believe that compile time check is an integral part of the development process to maintain or boost the quality.
My Firmware,Software, and Electronics Learning Adventure by 7String
This is my hobby and passion. :)
Thursday, October 1, 2015
Tuesday, September 29, 2015
MemMaker for .NET CF (Link)
A very nice and handy trick for optimizing memory usage on .NET CF Link
I currently applied it to my .NET CF project as well. :)
I currently applied it to my .NET CF project as well. :)
Sunday, August 9, 2015
Test-Driving CuTest Unit testing framework (and it's memory leak issues)
I am currently evaluating CuTest as I was supposed to use it for embedded systems development. Using a memory leak detector, I found out that there is a memory leak when suites are nested. I forked it and made some modifications on the CuTest source code to resolve the memory leak. The changes are very simple and was tested very lightly as of the moment. Source Code Link
Nevertheless, CuTest is a very good lightweight unit testing library.
Nevertheless, CuTest is a very good lightweight unit testing library.
Friday, August 7, 2015
RSA Encryption/Decryption Example Implementation for C#
Link to source code
Here is a very simple example implementation of RSA in C# using Private and Public key Encryption/Decryption. I also added an interface to be able to quickly switch between storage/loading of public/private keys either to/from memory or XML files.
Here is a very simple example implementation of RSA in C# using Private and Public key Encryption/Decryption. I also added an interface to be able to quickly switch between storage/loading of public/private keys either to/from memory or XML files.
Monday, June 29, 2015
AT Command Script Processor's Source Code (new github address)
I placed the source code here. Compiled with Visual Studio 2013 Community Edition. So far this was tested on the following devices:
- AT GSM Modems
- Bus Pirate
- ESP8266 (AT commands)
The link above contains the link for the Windows executable as well.
- AT GSM Modems
- Bus Pirate
- ESP8266 (AT commands)
The link above contains the link for the Windows executable as well.
Saturday, April 18, 2015
Programming Xilinx CoolRunner CPLD XC2C128 via Bus Pirate v3
For the past few days, I am having difficulties to make Bus Pirate v3 work with the stock XSVFplayer frmware JTAG from Dangerous Prototype's website. I fetched the latest source code from the SVN and modified the firmware. Now, my Bus Pirate can upload XSVF files generated by Xilinx ISE to my Xilinx Coolrunner xc2c128 CPLD.
I uploaded the hex file here Link. I used PicKit2 to upload the firmware and I didn't use the Bus Pirate's bootloader.
I uploaded the hex file here Link. I used PicKit2 to upload the firmware and I didn't use the Bus Pirate's bootloader.
Sunday, February 22, 2015
Protobuf-net - Did I initialize that list or not?
Protobuf-net is a very great binary serializer for .NET. I use it heavily on my project (memory, file, and over-the-wire serialization).
One of the confusions I recently had is that after I initialized a List, I assumed that it will be serialized into the stream. However, having a zero-length List, it always return null whenever protobuf deserializes the stream. I had seen some developers do a null checking or implement null-coalescing operator operations after they deserialize the stream and those null checking are scattered through-out the code (which violates the DRY principle and is ugly).
One very simple work-around for this is to provide a standard constructor and initialize the List on that constructor. Here is a sample unit test code which demonstrates that.
Special thanks to the protobuf-net author: Marc Gravell
One of the confusions I recently had is that after I initialized a List, I assumed that it will be serialized into the stream. However, having a zero-length List, it always return null whenever protobuf deserializes the stream. I had seen some developers do a null checking or implement null-coalescing operator operations after they deserialize the stream and those null checking are scattered through-out the code (which violates the DRY principle and is ugly).
One very simple work-around for this is to provide a standard constructor and initialize the List on that constructor. Here is a sample unit test code which demonstrates that.
Special thanks to the protobuf-net author: Marc Gravell
Subscribe to:
Posts (Atom)