Best Practices – File Names
With the advent of drag and drop technologies over the years, and with the depletion of core technical competencies, have come some pretty bad practices with file names. While most file name caveats have been addressed through the years they can still be a problem in some areas.
Unix type systems are case sensitive. Mixing upper and lower case in your HTML or other coding is going to be a very bad idea. And, while Windows supports some wide open boundaries with regards to file names, many of the programs which are installed on the computer may not be so lenient. Just because Windows can see the file doesn’t necessarily mean the program will.
The most common places which file names will affect you are really all of the important ones. Backup software or other scripting may react badly to spaces in file names, or special characters such as ` (which in Perl and many other environments is an escape shell code character). Another gotcha for file names is in SQL driven data sheets.
Basically if you boil your file creation habits down to the following guidelines life will be a lot simpler for your administrators and coders.
- Avoid mixing case. Always use lower case unless otherwise specified or markedly required.
- Do NOT put spaces in file names. This is a lazy mistake, and is causing your operating system lots of grief. Not to mention it can cause FTP and some scripting to malfunction. Instead substitute spaces with underscores. For example the file name “one two.pdf” should be “one_two.pdf”.
- Do NOT put special characters in file names. Examples of these are !@#$%^&*()
- If you store ordered data, or warehouse data, name files with the YYMMDDHHVV convention. This means you name the file beginning with (for today which is August 2, 2008) 08080213_sample.txt. In this case YY is the year, MM is the month, DD is the day, and VV represents a 2 digit sub-version number so that if you save more than one file per hour, you need’nt include seconds. In this way your files will automatically be delineated in their listing by the logical file name. Don’t put the date at the end of the filename because it breaks this convention.
- Keep file names under 16 characters long to avoid truncation of listed file names on some soft wares.
RF Engineering – Performance Reporting
Filed under: Engineering, RF Engineering, RF Engineering, Tech, Technology Engineering
SM OM DataGrid Design
Tired of having to run performance and trending reports?
Getting inaccurate results from your drop/block reports because of time shift?
Tired of handling such large amounts of data, and kludging through OMP data?
Designed for firms which use Lucent and Motorola switching with cellular networks (3G), we offer data grid design and implementation. We offer complete turn key solutions where your SM/OM data is imported hourly into a database, and using dynamic programming, and open source projects like PhP, Perl, Mysql, Apache, and JpGraph, we can design your interface custom tailored to you!
Imagine viewing your network performance metrics, spotting bad mobiles, high drop sites, all over your morning cup of coffee, and be in the field tilting antennae before first break! Think of the hundreds of thousands of dollars you’ll save in man hours as your engineers are free to zoom in on trouble spots using visual cues such as color-maps, and not sifting through tons of data and merging excel spreadsheets with VB macros!
With options like troposphere angle views on color-maps, you can literally get a birds eye view of meshed networks, overlapping service areas, and drill down to visit individual switch level metrics at a glance.
Forget out of the box solutions like Ocelot! Based around the original design (and from the original designer of Netwatch and Netwatch II) SM Data grid is by far the superior design, and tailored around your firm’s style of engineering.
Want to know more about how InnerTechnical can engineer SM/OM Data grid solutions for you? Fill out the form below to contact us, and we’ll arrange a meeting to discuss your needs: