Previous Next

User Rating: 0 / 5

Twitter

Share on Tumblr

Save this

Role Summary

Organize and supervise all of the administrative activities that facilitate the smooth running of the office. Supports company operations by maintaining office systems. This role is responsible for the organization and coordination of office operations, procedures and resources to facilitate organizational effectiveness and efficiency. The incumbent will also be responsible for managing the front office and customer care duties.

Duties and Responsibilities: 

• Welcomes visitors by greeting them in person or on the telephone; answering or referring inquiries.

• Update appointment calendars and schedule meetings/appointments.

• Petty cash management.

• Handling customer queries and directing them to the relevant party’s.

• Build sustainable relationship of trust through open and interactive communication.

• Provide accurate, valid and complete information by using the right methods/tools.

• Keep records of customer interactions, process customer accounts and file documents.

• Follow the right procedures, guidelines and policies while communicating courteously with customers by telephone, email, letter and face to face.

• Resolves administrative problems by coordinating preparation of reports, analyzing data, and identifying solutions.

• Maintains supplies inventory by checking stock to determine inventory level; anticipating needed supplies; placing and expediting orders for supplies; verifying receipt of supplies.

• Maintains continuity among work teams by documenting and communicating actions, irregularities, and continuing needs.

• Handling company logistics, staff travel, meeting preparation, car booking.

• In charge of office cleanliness and preparation of office tea.

• Any other duty as assigned.

Skills.

• Excellent command of verbal and written business English.

• Attention to details and problem solving.

• Strong organization and planning skills.

• Good presentation skills.

• Good time management skills

• Customer oriented and ability to adapt & respond to diverse culture.

Qualifications.

• Diploma in Business Management.

• Good knowledge of office software packages.

• Clerical and accounting knowledge.

• 2 years working experience in the same field.

• A valid driver’s license is an added advantage.

send a mail to careers@gbc.co.ke

Previous Next

User Rating: 0 / 5

Twitter

Share on Tumblr

Save this

Oracle recently lost its attempt to use patent and copyright law to force Google to pay US$9 billion for using parts of its Java computer language. Nine billion dollars isn’t chump change, not even for Google, but despite the verdict against Oracle, I’d say Google is not the only winner.

The dispute between the two internet giants was whether Google had needed Oracle’s permission to use computer code called the Java API. The API, and therefore the legal issue, relates to some pretty technical details about how computer programs work – how the instructions programmers write are followed on different hardware devices and different software operating systems.

The outcome of the case, decided in parts by a judge, an appeals court and a jury, was that Google’s use of computer code didn’t violate Oracle’s patents, and that Oracle could copyright its code. However, the jury found that Google’s use did not violate the copyright restrictions because it significantly expanded on the existing copyrighted materials, an exception in law called “fair use.”

It is not only a victory for Google, which has done nothing wrong and need not pay Oracle any money. Programmers remain allowed to use a very popular programming language without fear of crippling legal penalties – which in turn benefits the public, who use apps and websites made with Java. And while technically the legal loser, Oracle also won in a way, because it will benefit from Java’s continued popularity.
What’s an API?

To understand the heart of the dispute, we first need to grasp what an Application Programming Interface (API) is and what it does for programmers. At its simplest, an API defines the specific details of how a program interacts with a computer’s operating system and the underlying hardware.

Computer manufacturers use a wide range of specific components: hard drives and memory storage units with different sizes, faster or slower processing chips, smaller and larger screens. They also choose different operating systems, such as Windows, the Macintosh OS X, and Linux – each of which is regularly upgraded with a new version.
Hoping to avoid nightmares: a Java programmer. Joonspoon, CC BY-SA

Each variation might handle basic functions differently – such as reading a file connecting to the internet, or drawing images on the screen. For a computer programmer, that is a nightmare. Nobody wants to write a program that works only on a Dell laptop with a 15-inch screen, a 500 GB hard drive, 4 GB of RAM, running Windows 10 – and no other computer. And nobody wants to write the extremely large number of slight variations to make sure a program works on every machine, either.

The API solves that problem for the programmer, handling the complicated and difficult details of exactly how any specific computer will act. That leaves programmers free to concentrate on what they want a computer program to do, without having to worry about precisely how. It’s better for the user, too. If she has (for example) Java installed on whatever computer she uses, programs written in Java will run.
Java itself

The Java API contains methods for everything from reading and writing a file, to drawing on a screen, to handling web security certificates. Without a functioning copy of the API, programs in Java are fundamentally broken. Clearly, therefore, he who controls the API controls the language.

Oracle, when it bought Sun Microsystems, bought the rights to Java and its API. The crux of the legal battle was how this control is exerted and how far it extends.

No one denied that Oracle has a valid copyright on the language and API specification. This is a good thing. It means I can’t just make a copy of Java, give it a name (like “Darjeeling”), and call it a new language that I own. Similarly, a company can’t change the API arbitrarily and still call it the Java API.
What did Google do?

When it released Android in 2008, Google added software and hardware development to its existing internet service business. If its products were going to succeed, they needed to be able to run lots of interesting programs. The easiest way to do ensure that was to make sure the new devices could understand at least one computer language that’s already widely used by programmers. Java is a natural choice.

The alternative would have been to create a new language, but that pathway is fraught with difficulties. Introducing a new language requires convincing programmers that it is worth using and giving them time and resources to learn the language.

Once Google decided on Java, it needed to connect Java programs to Android’s hardware and software – it needed a Java API for Android.
Sharing names for computer commands

Rather than commissioning Oracle to write it, Google wrote the software in-house, customizing it for cellphone hardware. For example, Bluetooth, touch-screen gestures and telephone calls are not handled in Oracle’s standard Java API; they are solely in Android-specific code.

However, to be sure Android devices could run existing Java software, Google wrote its Android Java with some of the same commands as Oracle’s version of Java. Both Android and Oracle support the Java.io methods that let programmers use the same files.newInputStream(filename) command to initiate the arcane and complex Java file-reading process.

Google didn’t copy the code Oracle had written for other hardware or software systems. It wrote all-new Android-specific instructions for devices to follow each command, but to help programmers, gave many common commands the same name Oracle used.

Oracle’s lawyers sharpened their knives and the battle was on. Could Google use the same names, even if the code they referred to was different?
The stakes were high

If Oracle had won, Java’s days as a primary programming language for Android – the world’s most popular smartphone system – were numbered. Very quickly, Google would have chosen a new language for Android programmers to use, and published a conversion tool to translate existing Java apps into the new language. Then it would have stopped supporting Java. (I suspect one of Oracle’s competitors would have offered Google excellent licensing terms to choose another language.)

Programmers would have lost. The tools to write code for Android would have been, at a bare minimum, more expensive and less flexible. The public would have lost, because new and interesting apps would both be more expensive and released less frequently.

Finally, Oracle would have lost because programming in Java would no longer be a viable option for a major market. Computer languages compete for popularity, so fewer programmers would choose to program in Java, reducing the pool of people who were comfortable and competent in Java. Instead they would choose others, like Python or Ruby. With fewer people working in Java, Oracle’s primary way of making money from it (creating Java-based computer systems that can be expanded by third-party developers) would slowly decline.

Instead, while Oracle doesn’t get $9 billion from Google, the programming community – and those of us who use apps and websites every day – gets to keep using an important tool, without fear of a similarly large lawsuit in the future.

source: https://theconversation.com/google-wins-in-court-and-so-does-losing-party-oracle-60418

User Rating: 0 / 5

Twitter

Share on Tumblr

Save this

It's unbelievable to me that a company would pay a developer $60-$100k in salary, yet cripple him or her with terrible working conditions and crusty hand-me-down hardware. This makes no business sense whatsoever. And yet I see it all the time. It's shocking how many companies still don't provide software developers with the essential things they need to succeed.

I propose we adopt a Programmer's Bill of Rights, protecting the rights of programmers by preventing companies from denying them the fundamentals they need to be successful.

The Bill of Rights

Every programmer shall have two monitors

With the crashing prices of LCDs and the ubiquity of dual-output video cards, you'd be crazy to limit your developers to a single screen. The productivity benefits of doubling your desktop are well documented by now. If you want to maximize developer productivity, make sure each developer has two monitors.

Every programmer shall have a fast PC

Developers are required to run a lot of software to get their jobs done: development environments, database engines, web servers, virtual machines, and so forth. Running all this software requires a fast PC with lots of memory. The faster a developer's PC is, the faster they can cycle through debug and compile cycles. You'd be foolish to pay the extortionist prices for the extreme top of the current performance heap-- but always make sure you're buying near the top end. Outfit your developers with fast PCs that have lots of memory. Time spent staring at a progress bar is wasted time.

Every programmer shall have their choice of mouse and keyboard

In college, I ran a painting business. Every painter I hired had to buy their own brushes. This was one of the first things I learned. Throwing a standard brush at new painters didn't work. The "company" brushes were quickly neglected and degenerated into a state of disrepair. But painters who bought their own brushes took care of them. Painters who bought their own brushes learned to appreciate the difference between the professional $20 brush they owned and cheap disposable dollar store brushes. Having their own brush engendered a sense of enduring responsibility and craftsmanship. Programmers should have the same relationship with their mouse and keyboard-- they are the essential, workaday tools we use to practice our craft and should be treated as such.

Every programmer shall have a comfortable chair

Let's face it. We make our livings largely by sitting on our butts for 8 hours a day. Why not spend that 8 hours in a comfortable, well-designed chair? Give developers chairs that make sitting for 8 hours not just tolerable, but enjoyable. Sure, you hire developers primarily for their giant brains, but don't forget your developers' other assets.

Every programmer shall have a fast internet connection

Good programmers never write what they can steal. And the internet is the best conduit for stolen material ever invented. I'm all for books, but it's hard to imagine getting any work done without fast, responsive internet searches at my fingertips.

Every programmer shall have quiet working conditions

Programming requires focused mental concentration. Programmers cannot work effectively in an interrupt-driven environment. Make sure your working environment protects your programmers' flow state, otherwise they'll waste most of their time bouncing back and forth between distractions.

The few basic rights we're asking for are easy. They aren't extravagant demands. They're fundamental to the quality of work life for a software developer. If the company you work for isn't getting it right, making it right is neither expensive nor difficult. Demand your rights as a programmer! And remember: you can either change your company, or you can change your company.

source: http://blog.codinghorror.com/the-programmers-bill-of-rights

User Rating: 5 / 5

Twitter

Share on Tumblr

Save this

I am impressed by the work that went into the M-Pesa Generation II platform iteration.

While it has grown in complexity, it covers almost all the permutations that make for a more efficient business operation where the speed of cash flow is key to sustaining many enterprises.

We have, in the past, explored how the banking sector was caught napping, as Safaricom extended its focus from peer-to-peer money movement to business transactions.

This has a number of benefits on SMEs, both in relation to trade between themselves and trade with large enterprises.

The benefits of M-Pesa Gen II are best realised when hinged onto valued added platforms such as Lipisha, KopoKopo, WezaTele and others, which via application programming interfaces (APIs), can marry data generated by a firm and automate certain processes with business owners avoiding the back-end admin complexity on the M-Pesa Gen II dashboards.

Payment collections

We have already been doing this for years, with players such as Cellulant, PesaPal, JamboPay among others having built sizable business providing payment aggregator services to a growing number of customers, most notably utility companies.

The M-Pesa Gen II value that is realised is on the consumer side, where LipaNaMpesa online is poised for an overhaul that will see a departure from the use of the Bonga PIN to complete online transactions.

The possibility of push payments opens up a new avenue of opportunities in differentiated M an E commerce user experiences. The result will be higher value baskets and lower cart abandonment rates, where most attrition happens at checkout.

Supplier payments

With a growing number of businesses having adopted the paybill and buy goods facilities, it is now possible to move payments directly from one paybill number to another in real-time.

Think of a scenario where the enterprise resource planning platform or customer relationship management system raises a payment request to a customer with all parameters already embedded and it only takes a simple maker — checker process to have the payments approved and moved with all authorisations and know-your-customer verified.

Access to capital

The only downside to the M-Pesa Gen II ecosystem that would apply to businesses is access to additional support services, core of which is access to loans.

Any growing business will at some point in their lifetime require this facility, whether it is to fuel growth or service a purchase order.

source: http://www.businessdailyafrica.com/Pros-and-cons-of-M-Pesa-Generation-II-for-business/-/1248928/2723572/-/ojqj2nz/-/index.html