Data Center is our focus

We help to build, access and manage your datacenter and server rooms

Structure Cabling

We help structure your cabling, Fiber Optic, UTP, STP and Electrical.

Get ready to the #Cloud

Start your Hyper Converged Infrastructure.

Monitor your infrastructures

Monitor your hardware, software, network (ITOM), maintain your ITSM service .

Our Great People

Great team to support happy customers.

Saturday, February 27, 2010

[access] SMS API for Database developers (SQL)

If you use the OZEKI Message Server you can send and receive SMS messages using a database server with the help of SQL queries.

In order to use this option, you need to have a database server (such as Oracle, Access, MySql, MS SQL, Postgres, Sybes, etc) installed, and there should be two database tables created: ozekimessageout and ozekimessagein. One of these will be used for sending and the other for receiving SMS messages.

Ozeki Message Server will connect to the database through a standard ADO or ODBC connection (Figure 1). Using this connection it will periodically query the database table ozekimessageout for outgoing messages using a SELECT statement and will INSERT incoming messages into the database table used for incoming messages (ozekimessagein).














Figure 1. - Ozeki Message Server connecting to a database server

If you want to send a message you can issue the following SQL statement:

sql> INSERT INTO ozekimessageout (receiver,msg,id,status)
VALUES ('+36203105366','test message',23,'send');


It is important to mention that the SMS Server identifies the messages by their ids. You must make sure that you specify a unique id for each message or you should use auto_increment columns. This ID is used by Ozeki Message Server to update the status attribute of the message. For example if the message is accepted by the GSM service provider for delivery it's status field is updated to 'transmitted' to notify the database programmer what happened to the message.

The incoming messages are placed into the ozekimessagein table. You can see the create definition for this table at the url above as well. To view the incoming messages you can use the select statement.

sql> SELECT sender,msg,receivedtime FROM ozekimessagein;

+--------------+--------------+-------------------+
| sender | msg | receivedtime |
+--------------+--------------+-------------------+
| +36203105366 | test message | 01/11/03 08:43:32 |
+--------------+--------------+-------------------+
1 row in set (0.00 sec)


It is interesting that often, without any external application, you can create powerful SMS enabled solutions. You can do this with the help of database triggers or stored procedures. Here is an example:

Autoreply function with a Microsoft SQL Server:

CREATE TRIGGER autoreply ON ozekimessagein
FOR INSERT AS
DECLARE @tel VARCHAR(30)
SELECT TOP 1 @tel=sender FROM ozekimessagein ORDER BY ID DESC
INSERT INTO ozekimessageout (receiver,msg,status) VALUES (@tel,'Thank you for the message','send')
GO


[fch]

Manageengine has announced product life cycle plan for ManageEngine OpManager.

Product Life Cycle Plan

Manageengine has announced product life cycle plan for ManageEngine OpManager. OpManager 8.x version was released in February 2009 and has since been available for download. The older versions of OpManager, version 6.x and version 7.x series will be EOLed (End-Of-Life).

EOL Specification

Version | Build Nos. | Release Year | EOL Date | Supp.Ends On

OpManager 6.x | 6000 to 6016 | December 2005 | Feb 28, 2010 | May 31, 2010 |
OpManager 7.x | 7000 to 7206 | May 2007 | Feb 28, 2010 | Dec 31, 2010 |

EOL Details

We strongly encourage our users to upgrade to the latest version to benefit from the new features, critical bug fixes, enhancements, and the flexibility to opt for special add-ons and plug-ins. After every major release, we support the legacy releases for a considerable period of time to help our customers upgrade and/or migrate. With the general availability of OpManager 8.x since February 2009, we have decided to declare EOL for the earlier 2 major releases viz., Version 6.x and Version 7.x.

The EOL comes into effect from February 28, 2010. However, we will continue to extend technical support for Version 6.x till May 2010, and for Version 7.x till December 2010, taking care to see that you have ample time to upgrade and the process is hassle-free.

Note: Any bug-fixes, changes, or enhancements will not be made over version 6.x and 7.x henceforth.

Upgrade plans for existing customers:

1. If you are in version 6, write to opmanager-support@manageengine.com to get assistance on the upgrade path.
2. If you are in version 7, upgrade to the latest build by following the upgrade path detailed here.
3. For queries regarding renewal of your annual maintenance and support (AMS), get in touch with our sales team at fanky@dayaciptamandiri.com.

Thursday, February 25, 2010

[access] Selamat kepada OSA

Kami mengucapkan selamat kepada PT. OSA atas selesainya implementasi monitoring CCTV untuk kegiatan produksinya. Penggunaan CCTV semakin banyak digunakan, baik untuk monitoring security ataupun untuk penggunaan lainnya, seperti yang digunakan oleh PT. OSA.

Kami bangga melayani Anda.

10 ways to avoid mistakes during project development

* Date: February 22nd, 2010
* Author: Alan Norton
* Category: 10 things, Project management
* Tags: Project Development, Mistake, Project Management, Team Management, Quality, Human Capital Management, It Operations, It service Management, Management, Business Operations

The best strategy for dealing with mistakes is to avoid making them in the first place. Here are some tips to help you navigate around common project pitfalls.

You may have heard the phrase “Be proactive, not reactive.” It’s certainly appropriate when discussing how to best deal with mistakes. The idea, of course, is to prevent mistakes before they occur. But how exactly do you do that?” In this article, I will detail 10 real-world ways you can preempt mistakes during project development.

For the sake of simplicity, I’ve lumped all errors into one category: mistakes. The items listed here are specific to developers, but other IT roles can also benefit from many of them.


1: Learn from other’s mistakes

Find experienced peers who are willing to share their mistakes and then learn from them. I am somewhat biased, but the editors, writers, and members of TechRepublic seem willing to honestly share their mistakes — even if somewhat embarrassing at times.

2: Do your research first

No matter how much you know, you’ll encounter new challenges on an almost daily basis. Each challenge usually requires you to learn something new. Before you tackle a problem or task, do your homework. The trial-and-error method of learning may have been necessary and acceptable years ago. But with the resources available on the Internet today, there is little excuse for mistakes made because you didn’t do the proper research in advance.

3: Have a plan

You can’t know how to get to your destination without a roadmap. In project development, that roadmap is known as a project plan. Whether done formally or informally, you need to know how to get where you are going. Days or even weeks of programming time can be lost if the wrong path is taken. When done the right way, a project plan will help keep you from straying off course.

4: Follow standards and use templates

There are good reasons why experienced professionals took the time to create and publish industry and company standards. Standards detail best practices and procedures learned over years of trial and error.

Templates such as predefined forms can be useful since most of the work is already done in a standard format. A standard EULA approved by your legal counsel is another good example of a template that can come in handy if you are developing application software. A mistake in a legal document can be an expensive exercise — one best avoided.

5: Communicate and coordinate with others

If you are part of a team, it’s essential to communicate with other team members to avoid redundancies and to coordinate your work with theirs. Emails, instant messages, project status reports, and teleconferences are all ways to communicate and coordinate with others on the team. Unfortunately, each of these is far from perfect. You can spend the better part of a day reading and writing emails, participating in conference calls, and instant messaging with your peers. But it is a necessary part of the development process.

The perfect tool for communicating and coordinating with others in a team environment has yet to be developed. One of the better tools developed to share code is revision control software. Your project may also benefit from the use of a communication plan that ensures everyone involved — including customers and stakeholders — is kept apprised of key developments. (The TechRepublic downloads library has a free communication plan template to get you started.)

6: Allow enough time

It was at Hughes Aircraft Company that I first heard the phrase “You want it bad - you got it bad.” It didn’t happen very often, but when it did it was almost always made in reference to a part from a vendor that was badly needed, rushed through production, and upon arrival, failed testing. Failure to allow enough time for each phase of the project can lead to missed requirements, inadequate analysis, poor design, rushed programming, insufficient testing, and incomplete documentation. The result can be a system that doesn’t meet expectations and fails in one or more key areas.

Estimating the time needed to accomplish each phase of a project is difficult. I achieved the best results when I sat down with my supervisor and determined the time allotted for each major task in the project plan. I was overly optimistic in my estimates. He was much more realistic in his estimates, and he turned out to be right. As a rule of thumb, doubling my initial estimates came close to the actual time required. That information was useful for developing project plan timelines.

You may need to develop a similar rule of thumb until you can more accurately estimate completion dates. Ideally, you want to complete each phase of the project on time, and the best way to do that is estimate them correctly up front. Here are a few tips on creating realistic schedules.

7: Reuse proven code

If you’re an experienced developer, you should have built up a large code base over the years. Go blue and recycle this code whenever possible. You will likely have to modify the code to fit the new requirements, but proven core code is a good foundation to build on. Not only will you reduce the risk of introducing new bugs, but you will eliminate the time wasted creating similar code and the subsequent testing required.

Share your code with others so they can reuse parts of it. Proven code can be shared via plug-ins or libraries. Good external sources of code are available on the Internet that can be legally used for free or for a small fee.
8: Use checklists

Before a commercial plane trip, the pilot and co-pilot are busy walking through a long, detailed checklist. Checklists can be used during various phases of the project development process. They are particularly useful when working with large systems and when a single person is responsible for multiple tasks.

For example, a list detailing the steps required for system turn-on will help avoid accomplishing tasks out of order and prevent errors of omission. It is all too easy for developers to overlook important items like system access when they are busy doing final testing and documentation.

For more on the virtues of using checklists, see Leverage checklists to improve efficiency and client satisfaction.

9: Test, test, test… and carefully review your work

There is a healthy level of paranoia about delivering error-free work. Test as much as possible as early as possible. Errors in the code are typically more expensive to correct when found near the end of the development process. The last thing you need when facing a critical release date is to find a bug that should have been found months ago.

Careful and thorough testing will allow you to find those mistakes before your users can. Double- and triple-check your work. Develop test data and a plan to test common calendar-based events like EOM processing and annual reporting. All functionality and every single possible scenario should be thoroughly tested. And, yes, this is also a good place to use a checklist.

10: Test again with a third party

Find at least one experienced person who can be dedicated to the beta testing. They will undoubtedly use the system in ways you never dreamed of and find bugs you missed.

Don’t overlook or rush this final quality assurance task. It’s typically your last chance to get it right. Once a bad piece of software is released or a system with a critical bug is turned on, a company’s image can be tarnished for years to come.
The final word

One of the most important lessons I learned very early in my career is that a mistake isn’t a mistake until someone else knows about it. I was but a young inexperienced pup when I accidentally deleted some system files on a Tandem PC. It could have been a disaster. But I had enough sense and problem-solving skills to identify and copy over the missing files from another Tandem PC.

I have never told anyone until now about my near disaster. This may be obvious, but you should keep unseen mistakes to yourself. There is almost never anything to be gained by telling others you have done something really stupid. It can negatively affect your image and possibly damage your career.

I hope these proactive tips will help you avoid making an embarrassing mistake that becomes known to your boss, peers, and users. If you find yourself in that unenviable situation, you might want to read Calvin Sun’s article 10 things you should do if you make a big mistake.

I have always learned the most from my mistakes — but I prefer not making them in the first place.

http://blogs.techrepublic.com.com/10things/?p=1360&tag=nl.e040