Software Engineers Can Connect Better with their Team By Taking Their Interaction Up a Notch Using Cheers!

Hello there, I wanted to address one of the biggest challenges that many people face at work. Poor communication; this leads to misinterpretation, misunderstanding and ultimately frustration and unproductivity in the workplace. I wanna focus particularly on software engineers. For them, mostly all projects require working in a team and collaborating with others. Therefore, proper communication is an integral element for work optimization.  

Which can be hard when you work with a team that’s not always in the same room or even in the same country as you.  It is difficult to share and confirm ideas, knowledge and it’s even harder to explain complex concepts and requirements through text. Yes, you can have live conferences but they are not always ideal, due to different schedules, availability and you can only have those meetings so many times. And during those meetings, some people might be hesitant to ask questions or give their views. So, we resort to emails or other tools that provide online chats to communicate questions or ideas by writing them. Ex: slack. This is where you need a tool that will fill that communication gap. A tool that will help you be face-to face during your communications. This is why Cheers Video Mail is such an essential tool for software engineers. Rather than writing, communicate through videos. Put your ideas, views, knowledge, and concerns in a video to communicate adequately with your team. There is no doubt that we talk faster than we write and you for sure can get our point across better with more details by saying it instead of writing it.  Most people are visual and auditory learners. Text just might not be enough for them. They might have to see and hear something a couple of times to grasp a concept which people might avoid doing in a live-meeting. I know the value of cheers because I have used it myself to work better. Also, I document explanations and ideas using cheers to re-use them or to refer to them later which saves me a lot of time. Maybe I can create some videos to share with you guys how we use cheers in software development ; in design discussions, code review, software architecture, debugging. I highly suggest you guys to check out Cheers Video Mail and now is the perfect time since all cheers memberships are free. Most of us are working remotely so stay connected through cheers! I am sure your co-workers miss looking at your face and listening to your voice. Sign up for cheers today and stay tuned for more videos on how you can put CVM to good work for Software engineering

Good day, ladies and gentlemen and let me congratulate you on the progress so far. Our customer really appreciate the neat interface.We had a nice discussion.They love the idea of being able to collapse the menu and be able to have it saved per user preferences. They have the like a lot the implementation of the neat icons in here to attach or view documents based on the class.They also appreciate the ability to have the document name also listed and viewable.

The only thing that was subject to some kind of preference at the customer side, which I do strongly agree and I would like you to really work on refining that is the idea of the panel that collapse in here and also that is also savable to user preferences. What we would like to see is instead of the open and close icons that represent open and close as well as eliminating some or at least fifty percent of the space to the left and right. They like and I do like also the idea of clicking anywhere to open the panel, but if we could have a panel border in here or a framework that encapsulate the panel all together in here, that would be all so clear. A bit of more being definable as a panel collapsible or expandable. This definitely gives more space to be able to view the date and time versus having it like a bit narrower on on some areas specifically on screen resolutions that are lower than HD.  With that being said, please take necessary action to

adjust the close and open Button also enable a certain frame around the outer border for the panel by itself and on collapse let’s eliminate as much as possible of the free space.  You

know, very well that when you collapse the panel of the container, you're still looking also at the shipment down below and that shipment by itself fills the whole Space. We don't want really to have a lot of empty space on the top side. It doesn't really look as needed from a UI perspective for the client I appreciate your immediate attention to that. Thank you very much and good luck.

Hi, Dan, and John, this is Walid.

I have a simple message for you.

And I prefer to do it here as it makes it easier to look at from a different perspective rather than just writing a lot into the TFS and what I want you to do over there. Let me explain it a bit like guys, the whole logic, the whole component model has been implemented quite nicely except that I'm a bit concerned about how are we trapping the errors in here? So there is no implementation that tells me that we are really catching every specific error or possible bug that might happen inside the specific implementation. So let's look at it in simple parts. Whether you are implementing a FTP data exchange or you are implementing an SSH data exchange. It doesn't matter which one you are implementing, but look at the implementation here. Okay. So first we have a catch in here that is related directly to this top try which embodies all together the whole for each statement. So if I have multiple requests to this entity's Data exchange and I'm processing all of them; there could be a problem that may happen at any point in time here. And then it's going to break all together. Why can't we have a catch at every specific element so we can really catch that specific error and report it accordingly. The bLogger we are using is very detailed and very important. You're using it very well whether to catch errors at the level of the database Or in the code component elements or even you want to log something using user debug. I like the utilization here. However, if we are doing anything at the level of SSH importer or at the level of the FTP importer, the problem we're having is that if there is any error that will happen inside the specific process in here is going to break out directly to the catch all and everything in the process of the foreach will be broken. I would prefer an implementation that will tell me what broke exactly but continue processing everything else that is still okay to be dealt with so would you please implement a try/catch level anywhere in here whether at the SSH imported routine in here and remember you are into a multithreading environment and this is going to create different threads for each one of them. So, mainly a break out of this will break all the whole service interface and will not be running anymore. I prefer to know exactly why and where it happened and to be able to carry on with every other element of the data exchange that is really okay to happen. At the same token, the same issue is happening in the FTP importer and the SSH importer. For example, this is a nice catch in here you have a good try catch inside too which is good. That's what I like to see in the service itself. However, if I have a rename file in here that may end up having a certain technicality that will fail, I would have already processed that specific file download done in place, but I'm failing to rename. I also prefer to have a catch of what happens in here whether at the rename area or at the delete files area. So what we can do is that we know that this file has been already downloaded but we couldn't rename it and I would like also an implementation that tells me which file so we don't redownload and reprocess again. I think you need to talk to David about readjusting the component design if needed and work with that part as well. So, please take that into consideration and let's put some extended efforts into catching errors as much as possible and reporting them using the bLogger. You have the bLogger in place. So make use of it as much as possible. It gives you a lot of information and it will help you with tracking and debugging whatever you do specifically with this service that is tough to really maintain if you don't have proper information. Thank you very much for your kind attention. I look forward to seeing this resolved very soon. Bye for now.

The question was why we're still keeping an old  architectural design and we're spending efforts to be able to maintain that while by origin we are going  into a full new message transformation service. In this video message to you I'm not discussing the message transformation service adapter ;that we discussed before and we know that our notification service is going to go through the API Gateway and deliver a message to our message transformation service. Once a message is delivered, we will map it to a certain message transformation template which is exactly the map and then accordingly deal with the data and all the attributes elements received whether it's an XML file or Jason or any kind coming through our API and accordingly process and deposit it into the database to be able to be utilized in any further component. The reason why we are keeping the existing mechanism in place is that this legacy technologies that is currently in place and still in use by our customer and until we deploy our state-of-the-art application and services, we need to keep it in place because that's how the external service provider has been for ages delivering messages to the FTP sites and how our customer has been reading from whether FTP or SSH sites to be able to bring the message over.  We're maintaining the ability for the existing system to continue running both during the test mode of our technology and also during the

Parallel run whereby the customer would see how both systems are running and at the same time getting things into the new architectural we are building .We can't really let go; although you are all suffering from whatever is behind that specific piece of technology and I can't really say that is an architecture behind it. However, it's not about the state-of-the-art, not about best technology or about best architecture.

It's about what we have at hand? How do we deal with it? We need to maintain those parallel systems.

And once we are fully running, we will deprecate all that. Double work? That's not true. I heard you discussing double work, but it's not true the truth in all that is the ability to maintain the existing system. Get through the the parallel run, get the final customer approval to move over and then after moving over we will keep the existing system for backup but deprecate the whole process. This whole process on top in here will be deprecated once we move into our system. Please take necessary action, and I think that we have many of you who understand exactly why this is in place. My talk is simply to eliminate the need to discuss further architectural defects into the specific part . We are not going to discuss that or go into that; if you have anything to discuss within our own a new architecture, I would be more than happy to but for that one, please entertain the idea of keeping it up and running and that's going to be deprecated in the next 9-12 months.Thanks for your understanding.