Blog

Previous Next

User Rating: 0 / 5

Star InactiveStar InactiveStar InactiveStar InactiveStar Inactive

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

Add a comment

User Rating: 0 / 5

Star InactiveStar InactiveStar InactiveStar InactiveStar Inactive

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

Add a comment

User Rating: 5 / 5

Star ActiveStar ActiveStar ActiveStar ActiveStar Active

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

Add a comment
Previous Next

User Rating: 0 / 5

Star InactiveStar InactiveStar InactiveStar InactiveStar Inactive

A lot of people ask me things like ”What should I learn to get a programming job?” or ”How can I get a job as an engineer in Silicon Valley?”

Here’s an actual quote from last week:

So, I need some advice. I am 33 years old, and I need to get out of Support and in to at least DevOps if not full-stack development, but it’s so expensive. Any advice on what I should learn first?

The implication is usually which technology should you learn to get a job. As if your choice of technology is some kind of silver bullet.

Wanna know a dirty little secret? It doesn’t matter.

Any technology you’re likely to have heard of is a good pick. Does it have more than 10,000 results when you Google it? Then there are companies using it in production.

If companies are using it, then you can get a job doing it.

Ok, fine. There is a caveat: jobs are easier to get for technologies that are growing in popularity, and it’s harder to get a job in a technology that’s on its way out. So, maybe don’t pick FORTRAN or COBOL.

There’s another caveat — your choice of tech matters a lot more when you’re a programmer or developer than when you’re an engineer. That’s why engineers make $20,000 more than programmers on average.

Your real job as a software engineer isn’t to write code. It’s to translate hand-wavy business requirements into detailed specs that a computer can follow.

Your job is to ask questions and to find edge cases that the product people didn’t think of. Your job is to help operations define processes well enough to be automated.

Sure, you’ll write the code in the end, or maybe you’ll hand off the spec to a coder, but your real job is coming up with the spec. Even if it’s just in your head right before you write the code.

Don’t just learn a technology; learn how to solve problems with a technology.

The key here is that you have to play the long game. What interests you enough so that you can keep doing it for 10 years? It’s probably not a tech stack or a language, but a problem you want to solve.

Let’s say you work in support like that guy from the quote up top. What can you do to get a better job?

First, you can look at the job you already have. Are there problems you have or repetitive tasks you run into every day? You can probably automate those.

Start digging. Learn what you need to learn to solve your problem.

Then you look around. Are there any processes your team follows that are annoying? Processes that could be improved? Processes that you don’t use, but could make everyone’s lives better?

Then you can build something to make it easier. Start digging. Learn what you need. Someone who can take a loose problem and translate it into code is much more valuable than someone who can take specific instructions and write code.

Congratulations! You’re an engineer. You used technology to solve a real-world problem. And you didn’t even need anyone else to tell you the spec!

Not only is problem-oriented learning the most fun way to gain knowledge, it also teaches you all the other fringe skills that you need. Skills like turning fuzz into spec, Googling for solutions, digging into code to find bugs, talking to users, testing, and learning random new tech that’s handy. Learn all the things!

If you’re still stuck and don’t know which technology to use, go to HackerNews and find a “Who’s hiring” thread like this one. It’s a monthly collection of around 600–900 high quality jobs. Many of them list which technologies they use.

Read those threads. Count technology words. Pick the most popular 3. Learn them by solving a problem you have.

Be warned, though. That list changes completely every 2 or 3 years for libraries and frameworks and every 5 to 10 years for core technologies like languages, servers, and databases.

So don’t sweat the tech. Focus on learning to learn and solving problems. Be an engineer.

 

source: https://medium.com/swizec-s-nightowls/what-should-you-learn-to-get-a-better-coding-job-6453ef083597

Add a comment
Previous Next

User Rating: 0 / 5

Star InactiveStar InactiveStar InactiveStar InactiveStar Inactive

Scalar type declarations

Scalar type declarations come in two flavours: coercive (default) and strict. The following types for parameters can now be enforced (either coercively or strictly): strings (string), integers (int), floating-point numbers (float), and booleans (bool). They augment the other types introduced in PHP 5: class names, interfaces, array and callable.


<?php
// Coercive mode
function sumOfInts(int ...$ints)
{
    return array_sum($ints);
}

var_dump(sumOfInts(2, '3', 4.1));

The above example will output:

int(9)

To enable strict mode, a single declare directive must be placed at the top of the file. This means that the strictness of typing for scalars is configured on a per-file basis. This directive not only affects the type declarations of parameters, but also a function's return type (see return type declarations, built-in PHP functions, and functions from loaded extensions.

Full documentation and examples of scalar type declarations can be found in the type declaration reference.
Return type declarations

PHP 7 adds support for return type declarations. Similarly to argument type declarations, return type declarations specify the type of the value that will be returned from a function. The same types are available for return type declarations as are available for argument type declarations.


<?php

function arraysSum(array ...$arrays): array
{
    return array_map(function(array $array): int {
        return array_sum($array);
    }, $arrays);
}

print_r(arraysSum([1,2,3], [4,5,6], [7,8,9]));

 

The above example will output:

 

Array
(
    [0] => 6
    [1] => 15
    [2] => 24
)

 

Full documentation and examples of return type declarations can be found in the return type declarations. reference.
Null coalescing operator

The null coalescing operator (??) has been added as syntactic sugar for the common case of needing to use a ternary in conjunction with isset(). It returns its first operand if it exists and is not NULL; otherwise it returns its second operand.


<?php
// Fetches the value of $_GET['user'] and returns 'nobody'
// if it does not exist.
$username = $_GET['user'] ?? 'nobody';
// This is equivalent to:
$username = isset($_GET['user']) ? $_GET['user'] : 'nobody';

// Coalescing can be chained: this will return the first
// defined value out of $_GET['user'], $_POST['user'], and
// 'nobody'.
$username = $_GET['user'] ?? $_POST['user'] ?? 'nobody';
?>


Spaceship operator

The spaceship operator is used for comparing two expressions. It returns -1, 0 or 1 when $a is respectively less than, equal to, or greater than $b. Comparisons are performed according to PHP's usual type comparison rules.


<?php
// Integers
echo 1 <=> 1; // 0
echo 1 <=> 2; // -1
echo 2 <=> 1; // 1

// Floats
echo 1.5 <=> 1.5; // 0
echo 1.5 <=> 2.5; // -1
echo 2.5 <=> 1.5; // 1
 
// Strings
echo "a" <=> "a"; // 0
echo "a" <=> "b"; // -1
echo "b" <=> "a"; // 1
?>


Constant arrays using define()

Array constants can now be defined with define(). In PHP 5.6, they could only be defined with const.


<?php
define('ANIMALS', [
    'dog',
    'cat',
    'bird'
]);

echo ANIMALS[1]; // outputs "cat"
?>


Anonymous classes

Support for anonymous classes has been added via new class. These can be used in place of full class definitions for throwaway objects:


<?php
interface Logger {
    public function log(string $msg);
}

class Application {
    private $logger;

    public function getLogger(): Logger {
         return $this->logger;
    }

    public function setLogger(Logger $logger) {
         $this->logger = $logger;
    }
}

$app = new Application;
$app->setLogger(new class implements Logger {
    public function log(string $msg) {
        echo $msg;
    }
});

var_dump($app->getLogger());
?>

The above example will output:

object(class@anonymous)#2 (0) {
}

Full documentation can be found in the anonymous class reference.
Unicode codepoint escape syntax

This takes a Unicode codepoint in hexadecimal form, and outputs that codepoint in UTF-8 to a double-quoted string or a heredoc. Any valid codepoint is accepted, with leading 0's being optional.


echo "\u{aa}";
echo "\u{0000aa}";
echo "\u{9999}";

The above example will output:

ª
ª (same as before but with optional leading 0's)

Closure::call()

Closure::call() is a more performant, shorthand way of temporarily binding an object scope to a closure and invoking it.
<?php
class A {private $x = 1;}

// Pre PHP 7 code
$getXCB = function() {return $this->x;};
$getX = $getXCB->bindTo(new A, 'A'); // intermediate closure
echo $getX();

// PHP 7+ code
$getX = function() {return $this->x;};
echo $getX->call(new A);

The above example will output:

1
1

Filtered unserialize()

This feature seeks to provide better security when unserializing objects on untrusted data. It prevents possible code injections by enabling the developer to whitelist classes that can be unserialized.


<?php

// converts all objects into __PHP_Incomplete_Class object
$data = unserialize($foo, ["allowed_classes" => false]);

// converts all objects into __PHP_Incomplete_Class object except those of MyClass and MyClass2
$data = unserialize($foo, ["allowed_classes" => ["MyClass", "MyClass2"]]);

// default behaviour (same as omitting the second argument) that accepts all classes
$data = unserialize($foo, ["allowed_classes" => true]);
IntlChar

The new IntlChar class seeks to expose additional ICU functionality. The class itself defines a number of static methods and constants that can be used to manipulate unicode characters.


<?php

printf('%x', IntlChar::CODEPOINT_MAX);
echo IntlChar::charName('@');
var_dump(IntlChar::ispunct('!'));

The above example will output:

10ffff
COMMERCIAL AT
bool(true)

In order to use this class, the Intl extension must be installed.
Expectations

Expectations are a backwards compatible enhancement to the older assert() function. They allow for zero-cost assertions in production code, and provide the ability to throw custom exceptions when the assertion fails.

While the old API continues to be maintained for compatibility, assert() is now a language construct, allowing the first parameter to be an expression rather than just a string to be evaluated or a boolean value to be tested.


<?php
ini_set('assert.exception', 1);

class CustomError extends AssertionError {}

assert(false, new CustomError('Some error message'));
?>

 

The above example will output:

Fatal error: Uncaught CustomError: Some error message

Full details on this feature, including how to configure it in both development and production environments, can be found in the expectations section of the assert() reference.
Group use declarations

Classes, functions and constants being imported from the same namespace can now be grouped together in a single use statement.


<?php
// Pre PHP 7 code
use some\namespace\ClassA;
use some\namespace\ClassB;
use some\namespace\ClassC as C;

use function some\namespace\fn_a;
use function some\namespace\fn_b;
use function some\namespace\fn_c;

use const some\namespace\ConstA;
use const some\namespace\ConstB;
use const some\namespace\ConstC;

// PHP 7+ code
use some\namespace\{ClassA, ClassB, ClassC as C};
use function some\namespace\{fn_a, fn_b, fn_c};
use const some\namespace\{ConstA, ConstB, ConstC};
?>

Generator Return Expressions

This feature builds upon the generator functionality introduced into PHP 5.5. It enables for a return statement to be used within a generator to enable for a final expression to be returned (return by reference is not allowed). This value can be fetched using the new Generator::getReturn() method, which may only be used once the generator has finishing yielding values.


<?php

$gen = (function() {
    yield 1;
    yield 2;

    return 3;
})();

foreach ($gen as $val) {
    echo $val, PHP_EOL;
}

echo $gen->getReturn(), PHP_EOL;

The above example will output:

1
2
3

Being able to explicitly return a final value from a generator is a handy ability to have. This is because it enables for a final value to be returned by a generator (from perhaps some form of coroutine computation) that can be specifically handled by the client code executing the generator. This is far simpler than forcing the client code to firstly check whether the final value has been yielded, and then if so, to handle that value specifically.
Generator delegationGenerators can now delegate to another generator, Traversable object or array automatically, without needing to write boilerplate in the outermost generator by using the yield from construct.


<?php
function gen()
{
    yield 1;
    yield 2;
    yield from gen2();
}

function gen2()
{
    yield 3;
    yield 4;
}

foreach (gen() as $val)
{
    echo $val, PHP_EOL;
}
?>

The above example will output:

1
2
3
4

Integer division with intdiv()

The new intdiv() function performs an integer division of its operands and returns it.


<?php
var_dump(intdiv(10, 3));
?>

The above example will output:

int(3)

Session options

session_start() now accepts an array of options that override the session configuration directives normally set in php.ini.

These options have also been expanded to support session.lazy_write, which is on by default and causes PHP to only overwrite any session file if the session data has changed, and read_and_close, which is an option that can only be passed to session_start() to indicate that the session data should be read and then the session should immediately be closed unchanged.For example, to set session.cache_limiter to private and immediately close the session after reading it:

<?php
session_start([
    'cache_limiter' => 'private',
    'read_and_close' => true,
]);
?>
preg_replace_callback_array()

 

The new preg_replace_callback_array() function enables code to be written more cleanly when using the preg_replace_callback() function. Prior to PHP 7, callbacks that needed to be executed per regular expression required the callback function to be polluted with lots of branching.

Now, callbacks can be registered to each regular expression using an associative array, where the key is a regular expression and the value is a callback.
CSPRNG Functions

Two new functions have been added to generate cryptographically secure integers and strings in a cross platform way: random_bytes() and random_int().
list() can always unpack objects implementing ArrayAccess

Previously, list() was not guaranteed to operate correctly with objects implementing ArrayAccess. This has been fixed.

 

 

source: php.net

Add a comment

 

About Me

Oops...Almost forgot to say something about me. But anyway, I'm that guy, yule Msee, who'll sort out your techie issue and hails from the land of milk and honey. Not forgetting the bitter herbs too.

This is what am best at. Feel free to ask something. 

Latest Tweets

Search

Loading