OMG, what is this flip the buffer thing. I am ported back in time. Yes, that is what is happening. I have to edit a program in D3 and I forgot about flipping the buffer to see the changed code. It cannot be 1984 again. I did not like it when I first experienced D3 but it was not called D3 back then. What was it called? Maybe it was called OA or R83. Why should I care why is this editor so archaic? This is just a dream. I'm waking up now...
U2logic has created a full screen editor using the open source program Eclipse IDE for our D3 programmers. You can experience continuous compile of your D3 code. You can have a local history of all your changes to each program. You can have highlight reserved words that can be any color that Eclipse supports. You can edit D3 programs from you Mac or Windows work stations. You can see compiler errors via the Marker window by line number. You can see compiler error via console window.
Within Eclipse there is support for source code control for D3 via mainstream technologies like GIT, SVN, Team Foundation, and others. If you have a particular source code technology you like, they will have built an Eclipse plugin to access source code server.
Over time has we get going we will add the ability to copy from D3 to U2 and from U2 to D3. This will make porting or moving data from system to system pretty easy. We have use our copy and paste technology to copy between Universe and UniData for years. Our copy and paste technology allows us to copy data from server to server faster than most other U2 products saving you time.
Many D3 customers have already ask us to port many of our other tools to work with D3. We are prioritize them now and will be adding them over the next many months. Thanks to all of our beta testers for their valuable input whether it be a bug or a suggestion.
Showing posts with label Editor. Show all posts
Showing posts with label Editor. Show all posts
Wednesday, August 19, 2015
Thursday, November 8, 2012
Debugging versus Logging
Being first to the market with our XLr8Editor for Universe and Unidata, we were asked why we did not have a debugger. Most of the time the answer was that you could not hookup to Universe's RAID debugger or Unidata's debugger without Telnet session and some type of changes to both products. After Rocket Software's BDT came out with a debugger we looked at what they had done. Rocket Software had changed both Universe and Unidata to talk to Eclipse. Now our answer was that we needed access to the API they wrote for Eclipse.
In "The Practice of Programming" the authors Brian Kernighan and Rob Pike state: "As personal choice, we tend not to use debuggers beyond getting a stack trace or the value of a variable or two. One reason is that it is easy to get lost in details of complicated data structures and control flow; we find stepping through a program less productive than thinking harder and adding output statements and self-checking code at critical places. Clicking over statements takes longer than scanning the output of judiciously-placed displays. It takes less time to decide where to put print statements than to single-step to the critical section of code, even assuming we know where that is. More important, debugging statements stay with the program; debugging sessions are transient."
We have found the debugger certainly has its place but we are not Fan Boys. Whenever a program has HTML, JavaScript, and UniBasic code, how can you figure out where the problem lies? Maybe you are not even getting to your UniBasic code and your error is in the JavaScript. That is why we use Firebug's console.log statement in JavaScript which just prints out a log to the console. In our UniBasic code we call a logger throughout our code. This logger subroutine writes out data to a file which we can use later to figure out where our problem is.
We always do say that logging has its problems. It can slow down an application and calls to the logging subroutine are sometimes left in long after the problem is resolved. However, we find that the process is much cleaner and we can look at the output long after the program has been run.
In "The Practice of Programming" the authors Brian Kernighan and Rob Pike state: "As personal choice, we tend not to use debuggers beyond getting a stack trace or the value of a variable or two. One reason is that it is easy to get lost in details of complicated data structures and control flow; we find stepping through a program less productive than thinking harder and adding output statements and self-checking code at critical places. Clicking over statements takes longer than scanning the output of judiciously-placed displays. It takes less time to decide where to put print statements than to single-step to the critical section of code, even assuming we know where that is. More important, debugging statements stay with the program; debugging sessions are transient."
We have found the debugger certainly has its place but we are not Fan Boys. Whenever a program has HTML, JavaScript, and UniBasic code, how can you figure out where the problem lies? Maybe you are not even getting to your UniBasic code and your error is in the JavaScript. That is why we use Firebug's console.log statement in JavaScript which just prints out a log to the console. In our UniBasic code we call a logger throughout our code. This logger subroutine writes out data to a file which we can use later to figure out where our problem is.
We always do say that logging has its problems. It can slow down an application and calls to the logging subroutine are sometimes left in long after the problem is resolved. However, we find that the process is much cleaner and we can look at the output long after the program has been run.
Tuesday, November 6, 2012
Vindication of our Release Strategy
Many U2 (Universe and Unidata) programmers had disliked and voiced their opinion negatively when U2logic announced many years ago that our XLr8 Tools was going to 3 to 4 week release cycle. We felt that most of our bugs and enhancements could be released after they had been completed, unit tested and quality tested. While Firefox, Chrome, and Safari browsers were getting released at least every month and half, we did not see any reason we could not do the same even though we have a smaller team.
Just the other day Rocket Software announced that it has been releasing it's Eclipse based tools almost every month since March of this year. They also stated that they had fixed around 60 bugs, plus added many new features. A competitor vindicates our strategy.
During the same period as Rocket Software, U2logic has enhanced and fixed over 140 items. We should be patting ourselves on our back for a job well done. This represents a lot of work from our staff of programmers, testers, QA's, and customers.
Whenever we are going through our Bugzilla items and deciding what we will tackle in the next few weeks, we are always aware of this mandated release schedule. We have stopped working on some enhancements because they are taking too long and would contribute to a slower release schedule.
The question becomes can we keep this strategy going for more than a couple of years? Is this strategy harmful to our customer base? And last but not least, can we remember what the release numbers mean after 10 or 15 releases?
Just in case you have not updated your copy XLr8 Tools, the current release is 3.5.15 which was released yesterday.
Just the other day Rocket Software announced that it has been releasing it's Eclipse based tools almost every month since March of this year. They also stated that they had fixed around 60 bugs, plus added many new features. A competitor vindicates our strategy.
During the same period as Rocket Software, U2logic has enhanced and fixed over 140 items. We should be patting ourselves on our back for a job well done. This represents a lot of work from our staff of programmers, testers, QA's, and customers.
Whenever we are going through our Bugzilla items and deciding what we will tackle in the next few weeks, we are always aware of this mandated release schedule. We have stopped working on some enhancements because they are taking too long and would contribute to a slower release schedule.
The question becomes can we keep this strategy going for more than a couple of years? Is this strategy harmful to our customer base? And last but not least, can we remember what the release numbers mean after 10 or 15 releases?
Just in case you have not updated your copy XLr8 Tools, the current release is 3.5.15 which was released yesterday.
Wednesday, July 8, 2009
Horse Blinders for U2 Programmers
Over the course of many years we have wondered why U2 UniBasic programmers still insist on coding with vi, notepad, ED or AE. The latter two are line by line editors that were developed in the 1980's and are installed with the database. So coding with horse blinders on seems to fit some of our esteemed colleagues.
Many programmers believe ED or AE keeps them focused on what is in front of them, encouraging them to pay attention to the code rather than other distractions. ED or AE programmers are commonly seen to help keep them from being distracted or spooked. See the real Wikipedia explanation http://en.wikipedia.org/wiki/Blinders and not the satirical piece that was co-opted in this paragraph.
That not to say they cannot do the job or that the job they do does not have value with those tools. The point really here is that some U2 programmers are stuck in the 1980's coding with those tools or have some hybrids that have been cobbled together from various open source projects. Why should we not be programming like millions of Java, C#, and VB programmers that have great tools.
We can have state of the art tools with full screen editors, reserved word colorization, syntax completion, cognitive help, local or database editing, search, local history change log, and version control to name a few of the new features. Bugzilla or other connectors can be attached to some editors an allow you to see what bugs you have to fix or software you have to enhance.
Some enlightened programmers live all day in their tool set and very rarely wander into the world of TCL (terminal control language). Of course, we know a few of them.
Eclipse platform is what IBM, the former owner of the U2 databases, believes is the integrated development platform of the future. Eclipse is used by hundreds of thousands of programmers. There are plug-ins for many languages such as Java, PHP, Cobol, C++, and C# to name a few that come to mind. There are thousands of other plugs-in to do whatever you can think of.
The Basic Developer Toolkit that is part of client software for U2 databases since 2008. The Basic Developer Toolkit is free when you upgrade your database. The other Eclipse developer is from U2logic, Inc. and it is called XLr8Editor. XLr8Editor has been on the U2 market since late 2006.
It time to change old habits and move to the 21st century.
Many programmers believe ED or AE keeps them focused on what is in front of them, encouraging them to pay attention to the code rather than other distractions. ED or AE programmers are commonly seen to help keep them from being distracted or spooked. See the real Wikipedia explanation http://en.wikipedia.org/wiki/Blinders and not the satirical piece that was co-opted in this paragraph.
That not to say they cannot do the job or that the job they do does not have value with those tools. The point really here is that some U2 programmers are stuck in the 1980's coding with those tools or have some hybrids that have been cobbled together from various open source projects. Why should we not be programming like millions of Java, C#, and VB programmers that have great tools.
We can have state of the art tools with full screen editors, reserved word colorization, syntax completion, cognitive help, local or database editing, search, local history change log, and version control to name a few of the new features. Bugzilla or other connectors can be attached to some editors an allow you to see what bugs you have to fix or software you have to enhance.
Some enlightened programmers live all day in their tool set and very rarely wander into the world of TCL (terminal control language). Of course, we know a few of them.
Eclipse platform is what IBM, the former owner of the U2 databases, believes is the integrated development platform of the future. Eclipse is used by hundreds of thousands of programmers. There are plug-ins for many languages such as Java, PHP, Cobol, C++, and C# to name a few that come to mind. There are thousands of other plugs-in to do whatever you can think of.
The Basic Developer Toolkit that is part of client software for U2 databases since 2008. The Basic Developer Toolkit is free when you upgrade your database. The other Eclipse developer is from U2logic, Inc. and it is called XLr8Editor. XLr8Editor has been on the U2 market since late 2006.
It time to change old habits and move to the 21st century.
Subscribe to:
Posts (Atom)