Tag Archives: Send File

Linux

Validate input files and update

Leave a comment

By katakamvivek

We have a job which we need to run on daily bases, before loading data in a table we need to validate whether the input file is received or not.Inputfile formatsrc_sps_d_Call_Center_Reporting_yyyymmdd_01.dat SPS-Service nameYYYY-yearMM-MonthDD-dayLike above we will get n number of files for different services.SS_list.txt File contains data like below1)SPS2)OCWEN3)XYZ Ss_load_proc_day tableS_servicer_code Load_Date File_Recv_D1 File_Recv_D2SPS TUE MON FRISPS Wed Tue SPS Thu Wed SPS Fri Thu SS_Calendar tableS_Servicer_code Date No_File_Receive_Day ( etc) Month_EndSPS 3/29/20013 N YSPS 4/1/2003 Y NOCWEN 4/1/2003 N NXYZ 3/30/20013 N N1. Take one sub servicer vendor name from SS_List.txt and perform #2  #6Check ../SrcFiles , if file for this vendor available today  src_sps_d_Call_Center_Reporting_yyyymmdd_01.dat 2. If Yes, start from #13. Else , Check if load date(currentday) for this vendor is No_File_Receive_Day in SS_Calendar table4. If Yes, start from #15. If Not, Send File missing ALERT with file name.1. Take one sub servicer vendor name from SS_List.txt and perform #2  #42. append VendorName-Day ( viz ‘SPS-TUE’). Check SS_Procday.txt for any entry. If Not* start #13. If Yes, Get the days ( MON, FRI ); Check all the received files’ Proc_Dates (embedded in file name) They should match. 4. If missing any, Send ALERT with file names. If the source file exist then it should update output file name as …read more
Source: FULL ARTICLE at The UNIX and Linux Forums
Linux

BlueDevil: Changing the way we work

Leave a comment

In short:
From now on we will be maintaining only one release instead of 4. We are going to focus on 1.3 and try to fix all remaining bugs, then we will work on implementing some of the reported wishes and release 1.4. Once that happens we will only maintain 1.4.

Explanation:
Since BlueDevil was released we have been updating all stable versions, which means:

  • 1.0 (currently at 1.0.5)
  • 1.1 (currently at 1.1.5)
  • 1.2 (currently at 1.2.4)
  • 1.3 (about to release 1.3.1)

This has been possible because the code base did not change much between releases so we fixed the bugs in the oldest version and then forwarded the fix to all the other releases, this was the easy part.

Before each release we like to do some intense testing to make sure that none of the basic functionality has been broken. In the hardware world quality is extremely important, we do not want to leave the user without a mouse, connectivity or an usable screen just because we are lazy or we don’t feel like doing QA.

In the case of BlueDevil we test most of this before each release (independently of what code has been modified):http://community.kde.org/Solid/Projects/BlueDevil/Tests

This means that even if the “Send File” functionality was NOT modified in a new release, we test it just in case something broke.

In the list there are more or less 60 items, lets say it takes 1 minute per item to test it (it takes more) that means that it will take roughlyan hour to test an entire release. Now multiply this per 4 which is the number of releases we have been doing and you will get 4 hours we invest on QA.

Besides the work we do before each release there is a constant effort of bug triaging that becomes way more difficult when you support a variety of versions since it makes you have to switchto a given version to try to reproduce and fix a bug you can’t reproduce with the version you are using.

If it is that much trouble, why have you been doing it?
In one word: distributions. Each distribution has a different time table, each distribution has a different minor release policy, each distribution is a different world. At the time we started doing this, Bluetooth in KDE was a mess so the highest priority was to have a good experience in alldistributions. It should not matter which Bluedevlil version they were using.

Nowadays the situation has changed, we work quite well in all published versions so if a distribution does not upgrade (for whatever reason) the user won’t die.

So, now what?
From now on we are going to maintain only one version, and we are not going to support (or give support) to any other. This means that if a bug is reported with an old version the first thing we are going to ask is to upgrade and test again (if the part that issupposedlybroken has been …read more
Source: FULL ARTICLE at Planet KDE