8 Tips To Improve Cyber Security This Year!

Cyber security has become really important aspect over last few years. We can always leverage cutting-edge technology to address to new threats. The new practices and human behaviour can lead to cyber crime free year or at least we can minimize the risks. Here are eight tips to secure your cyber footprints.

1. Cyber Hygiene

Majority of cyber attacks are attempts of failure of basic cyber hygiene such as patching vulnerable systems. You can apply basic cyber hygiene behaviours to mitigate majority of known attack vectors. Users can implement the cuticle basics and organisations can make productive use of limited resource to focus on more difficult cyber challenges.

2. Monitor Your Network

You need to maintain document of inventory and connections of your network. In case of organization, you can count and document the type of device, its location and assigned owner of IT assets. The assets include, computer setup, smartphones, thumb drives, printers, routers and servers. You can implement policy that requires users to create and maintain complete and accurate IT asset inventory.

3. Key Security Settings

You need to identify hardware and applications running in your business. The focus should be on operating systems as they are the key element behind every attack. You should research trusted and secure configuration for each type of hardware and application. Implementing key security settings can protect your system from basic fundamental attacks.

4. Control

As a head of hierarchy, you can implement the process to manage identities and credentials for authorized users. You can limit access to devices containing sensitive data. Associating facilities to authorized users, processes or devices is the best way of keeping tabs on who accesses your system. You can educate people in your organization about how to use their account credentials. Implementing a system that keeps log of access and usage can help you track cyber bullies.

5. Patch

Time to time patching of bugs and issues is best practice of maintaining confidentiality, integrity and availability of systems and information. You can review technology asset inventory of your organization and identify software operations on these assets. Reviewing patches, updates and revisions can protect you from third-party cyber attacks.

6. Repeat

Cyber security threats continue to evolve over time so, ultimately cyber security is ongoing process that requires constant updates. You need to repeat the security measures after equal interval of time. The repeat list should ensure that each cycle of individual priority has appropriately met and there is no fall or crack in cyber health maturity.

7. Human Factor

Even though we live in online era, human factor still plays great role in organisation’s cyber security. You cannot assume that everyone understands his individual responsibility when it comes to cyber security. Small amount of workforce doesn't believe that they are responsible for security of their networks. You need to train and educate your employees about the cyber hygiene and best practices. This is the only way you can improve organisation’s security in this year.

8. Collaboration

Regardless of size, cyber threats impact all businesses. The threats are pretty complex. The number of threats and severity is too high for any small workforce to handle. You need to use the power of collaborative energy to fight against cyber threats. 



Courtesy:- efytymes

Two years in the making, Node.js upgrade arrives

In development for nearly two years, the 0.12 release of Node.js is about to become available. Whether the release can mend the now-fractured community that has been built around the popular server-side JavaScript platform remains to be seen.

Officials at Node.js steward Joyent and at Strongloop, which is involved in Node.js development, provided InfoWorld details about the upcoming release, for which thedownload should become available today.

Version 0.12 will feature round-robin clustering, providing for better distribution of Node.js across processor cores. It also will have performance optimizations including reduced garbage-collector strain. Profiling APIs in 0.12 improve memory management. Users also can run multiple instances in a single process via a multicontext capability. Clustered apps can be debugged with the Node-Inspector capability. Also supported is execSync, a synchronous API for child processes. There are also improvements in the TLS (Transport Layer Security) function.

Although the Node community at large might breathe a collective sigh of relief that version 0.12 is finally here, frustration with the pace of upgrades to the platform was a principal reason for the recent forking of Node.js, via the io.js fork. Strongloop's Bert Belder, who is deeply involved in both the development of Node.js as well as io.js, said he still expects to be working on both projects. Io.js went to a beta release last month. It features capabilities now being fitted into Node.js 0.12, such as round-robin clustering and virtual machine improvements, Belder said.

A founder of API server vendor Strongloop, Belder is a Node core contributor and a member of the io.js technical committee. He said he anticipates a reconciliation between the two factions at some point, hopefully within a half year. Right now, there are two versions of Node.js (also called Node), thanks to the io.js fork. "I think it's wasteful to have to have two projects," Belder said. Io.js proponents "really took that position that we wanted to release really frequently."

Asked about the io.js fork, Joyent's TJ Fontaine, project lead for Node.js, avoided any criticism, saying he welcomed more participation in JavaScript at the server level, which io.js enables. "It's a fantastic opportunity for Node.js."

Beyond version 0.12, the focus for Node.js will be on reconciliation in the Node.js community and improving the governance model, Belder said. Fontaine said discussions about an eventual 1.0 release of Node.js are expected to happen at the Node Summit conference in San Francisco next week.

Although proponents see Node.js as production-ready now, the 1.0 release would have to ensure that no APIs are broken, and to do that APIs that need to change have to be identified first, Fontaine said. "[Version] 1.0 is an important step, and it means that we will be supporting these APIs in perpetuity."

This story, "Two years in the making, Node.js upgrade arrives" was originally published by InfoWorld.

Modularity in Java 9: Stacking up with Project Jigsaw, Penrose, and OSGi

This article provides an overview of proposals, specifications, and platforms aimed at making Java technology more modular in Java 9. I'll discuss factors contributing to the need for a more modular Java architecture, briefly describe and compare the solutions that have been proposed, and introduce the three modularity updates planned for Java 9, including their potential impact on Java development.

Why do we need Java modularity?

Modularity is a general concept. In software, it applies to writing and implementing a program or computing system as a number of unique modules, rather than as a single, monolithic design. A standardized interface is then used to enable the modules to communicate. Partitioning an environment of software constructs into distinct modules helps us minimize coupling, optimize application development, and reduce system complexity.

Modularity enables programmers to do functionality testing in isolation and engage in parallel development efforts during a given sprint or project. This increases efficiency throughout the entire software development lifecycle.

Some characterizing attributes of a genuine module are:

• An autonomous unit of deployment (loose coupling)
• A consistent and unique identity (module ID and version)
• Easily identified and discovered requirements and dependencies (standard compile-time and deployment facilities and meta-information)
• An open and understandable interface (communication contract)
• Hidden implementation details (encapsulation)

Systems that are built to efficiently process modules should do the following:

• Support modularity and dependency-discovery at compile-time
• Execute modules in a runtime environment that supports easy deployment and redeployment without system downtime
• Implement an execution lifecycle that is clear and robust
• Provide facilities for easy registry and discovery of modules

Object-oriented, component-oriented, and service-oriented solutions have all attempted to enable pure modularity. Each solution has its own set of quirks that prevent it from achieving modular perfection, however. Let's briefly consider.

Java classes and objects as modular constructs

Doesn't the object-oriented nature of Java satisfy the requirements of modularity? After all, object-oriented programming with Java stresses and sometimes enforces uniqueness, data encapsulation, and loose coupling. While these points are a good start, notice the modularity requirements that aren't met by Java's object-oriented framework: identity at the object level is unreliable; interfaces are not versioned: and classes are not unique at the deployment level. Loose coupling is a best practice, but certainly not enforced.

Reusing classes in Java is difficult when third-party dependencies are so easily misused. Compile-time tools such as Maven seek to address this shortcoming. After-the-fact language conventions and constructs such as dependency injection and inversion-of-control help developers in our attempts to control the runtime environment, and sometimes they succeed, especially if used with strict discipline. Unfortunately, this situation leaves the chore of creating a modular environment up to proprietary framework conventions and configurations.

Java also adds package namespaces and scope visibility to the mix as a means for creating modular compile-time and deployment-time mechanisms. But these language features are easily sidestepped, as I'll explain.

Packages as a modular solution

Packages attempt to add a level of abstraction to the Java programming landscape. They provide facilities for unique coding namespaces and configuration contexts. Sadly, though, package conventions are easily circumvented, frequently leading to an environment of dangerous compile-time couplings.

The state of modularity in Java at present (aside from OSGi, which I will discuss shortly) is most often accomplished using package namespaces, JavaBeans conventions, and proprietary framework configurations like those found in Spring.

Aren't JAR files modular enough?

JAR files and the deployment environment in which they operate greatly improve on the many legacy deployment conventions otherwise available. But JAR files have no intrinsic uniqueness, apart from a rarely used version number, which is hidden in a .jar manifest. The JAR file and the optional manifest are not used as modularity conventions within the Java runtime environment. So the package names of classes in the file and their participation in a classpath are the only parts of the JAR structure that lend modularity to the runtime environment.

In short, JARs are a good attempt at modularization, but they don't fulfill all the requirements for a truly modular environment. Frameworks and platforms like Spring and OSGi use patterns and enhancements to the JAR specification to provide environments for building very capable and modular systems. Over time, however, even these tools will succumb to a very unfortunate side-effect of the JAR specification JAR hell!

Classpath/JAR hell

When the Java runtime environment allows for arbitrarily complex JAR loading mechanisms, developers know they are in classpath hell or JAR hell. A number of configurations can lead to this condition.

First, consider a situation where a Java application developer provides an updated version of the application and has packaged it in a JAR file with the exact same name as the old version. The Java runtime environment provides no validation facilities for determining the correct JAR file. The runtime environment will simply load classes from the JAR file that it finds first or that satisfies one of many classpath rules. This leads to unexpected behavior at best.

Another instance of JAR hell arises where two or more applications or processes depend on different versions of a third-party library. Using standard class-loading facilities, only one version of the third-party library will be available at runtime, leading to errors in at least one application or process.

A full-featured and efficient Java module system should facilitate separation of code into distinct, easily understood, and loosely coupled modules. Dependencies should be clearly specified and strictly enforced. Facilities should be available that allow modules to be upgraded without having a negative effect on other modules. A modular runtime environment should enable configurations that are specific to a particular domain or vertical market, thus reducing the startup time and system footprint of the environment.

Modularity solutions for Java

Along with the modularity features mentioned so far, recent efforts add a few more. The following features are intended to optimize performance and enable extending the runtime environment:

• Segmented source code: Source code separated into distinct, cached segments, each of which contains a specific type of compiled code. The goals of which include skipping non-method code during garbage sweeps, incremental builds, and better memory management.
• Build-time enforcements: Language constructs to enforce namespaces, versioning, dependencies, and others.
• Deployment facilities: Support for deploying scaled runtime environments according to specific needs, such as those of a mobile device environment.

A number of modularity specifications and frameworks have sought to facilitate these features, and a few have recently risen to the top in proposals for Java 9. An overview of Java modularity proposals is below.

JSR (Java Specification Request) 277

Currently inactive is Java Specification Request (JSR) 277, the Java Module System; introduced by Sun in June of 2005. This specification covered most of the same areas as OSGi. Like OSGi, JSR 277 also defines discovery, loading, and consistency of modules, with sparse support for runtime modifications and/or integrity checking.

Drawbacks to JSR 277 include:

• No dynamic loading and unloading of modules/bundles
• No runtime checks for class-space uniqueness

OSGi (Open Service Gateway Initiative)

Introduced by the OSGI Alliance in November of 1998, the OSGI platform is the most widely used modularity answer to the formal standard question for Java. Currently atrelease 6, the OSGi specification is widely accepted and used, especially of late.

In essence, OSGi is a modular system and a service platform for the Java programming language that implements a complete and dynamic component model in the form of modules, services, deployable bundles, and so on.

The primary layers of the OSGI architecture are as follows:

• Execution environment: The Java environment (for example, Java EE or Java SE) under which a bundle will run.
• Module: Where the OSGi framework processes the modular aspects of a bundle. Bundle metadata is processed here.
• Life-cycle: Initializing, starting, and stopping of bundles happens here.
• Service registry: Where bundles list their services for other bundles to discover.

One of the biggest drawbacks to OSGi is its lack of a formal mechanism for native package installation.

JSR 291

JSR 291 is a dynamic component framework for Java SE that is based on OSGi, is currently in the final stage of development. This effort focuses on taking OSGi into mainstream Java, such as was done for the Java mobile environment by JSR 232.

JSR 294

JSR 294 defines a system of meta-modules and delegates the actual embodiment of pluggable modules (versions, dependencies, restrictions, etc.) to external providers. This specification introduces language extensions, such as "superpackages" and hierarchically-related modules, to facilitate modularity. Strict encapsulation and distinct compilation units are also part of the spec's focus. JSR 294 is currently dormant.

Project Jigsaw

Project Jigsaw is the most likely candidate for modularity in Java 9. Jigsaw seeks to use language constructs and environment configurations to define a scalable module system for Java SE. Primary goals of Jigsaw include:

• Making it very easy to scale the Java SE runtime and the JDK down to small devices.
• Improving the security of Java SE and the JDK by forbidding access to internal JDK APIs and by enforcing and improving the SecurityManager.checkPackageAccessmethod.
• Improving application performance via optimizations of existing code and facilitating look-ahead program optimization techniques.
• Simplifying application development within Java SE by enabling libraries and applications to be constructed from developer-contributed modules and from a modular JDK
• Requiring and enforcing a finite set of version constraints

JEP (Java Enhancement Proposal) 200

Java Enhancement Proposal 200 created in July of 2014, seeks to define a modular structure for the JDK. JEP 200 builds on the Jigsaw framework to facilitate segmenting the JDK, according to Java 8 Compact Profiles, into sets of modules that can be combined at compile time, build time, and deploy time. These combinations of modules can then be deployed as scaled-down runtime environments that are composed of Jigsaw-compliant modules.

JEP 201

JEP 201 seeks to build on Jigsaw to reorganize the JDK source code into modules. These modules can then be compiled as distinct units by an enhanced build system that enforces module boundaries. JEP 201 proposes a source-code restructuring scheme throughout the JDK that emphasizes module boundaries at the top level of source code trees.

Penrose

Penrose would manage interoperability between Jigsaw and OSGi. Specifically, it would facilitate the ability to modify OSGi micro-kernels in order for bundles running in the modified kernel to utilize Jigsaw modules. It relies on using JSON to describe modules.

Plans for Java 9

Java 9 is a unique major release for Java. What makes it unique is its introduction of modular components and segments throughout the entire JDK. The primary features supporting modularization are:

• Modular source code: In Java 9, the JRE and JDK will be reorganized into interoperable modules. This will enable the creation of scalable runtimes that can be executed on small devices.
• Segmented code cache: While not strictly a modular facility, the new segmented code cache of Java 9 will follow the spirit of modularization and enjoy some of the same benefits. The new code cache will make intelligent decisions to compile frequently accessed code segments to native code and store them for optimized lookup and future execution. The heap will also be segmented into 3 distinct units: non-method code that will be stored permanently in the cache; code that has a potentially long lifecycle (known as "non-profiled code"); and code that is transient (known as "profiled code").
• Build-time enforcements: The build system will be enhanced, via JEP 201, to compile and enforce module boundaries.
• Deployment facilities: Tools will be provided within the Jigsaw project that will support module boundaries, constraints, and dependencies at deployment time.

Java 9 early access release

While the exact release date of Java 9 remains a mystery, you can download an early access release at Java.net.

In conclusion

This article has been an overview of modularity within the Java platform, including prospects for modularity in Java 9. I explained how long-standing issues like classpath hell contribute to the need for a more modular Java architecture and discussed some of the most recent new modularity features proposed for Java. I then described and contextualized each of the Java modularity proposals or platforms, including OSGi and Project Jigsaw.

The need for a more modular Java architecture is clear. Current attempts have fallen short, although OSGi comes very close. For the Java 9 release Project Jigsaw and OSGi will be the main players in the modular space for Java, with Penrose possibly providing the glue between them.

This story, "Modularity in Java 9: Stacking up with Project Jigsaw, Penrose, and OSGi" was originally published by javaWorld.

Untangling the intense politics behind Node.js

The news that broke at the Node Summit last week -- that Joyent and others are proposing to create a Node.js Foundation -- came as no surprise to anyone who has been watching the controversy around everyone's favorite server-side JavaScript platform. It’s been clear for a while that Node.js has outgrown its roots and become an important structural tool for the software industry.

Node has seen grassroots adoption that has led to enterprise deployments of the kind many recognize in open source, where CIOs are sure the technology isn’t in use in their business until they actually ask the operations staff. That in turn has led to the usual dichotomy between the needs of operations teams for stability (change only where it’s needed, preferably infrequently after rigorous testing) and the outlook of developers (who want to try every new idea now or sooner).

As might be expected of a company with a deep commitment to stable operations, Joyent falls firmly in the first camp. Its operations focus is supported by large deployers of Node applications globally, some of whom can be found guiding the new Node Foundation.

But widespread adoption also spawns startups looking to exploit new needs and monetize their resolution. Plenty of those startups are involved in the io.js fork of Node.js, calling for frequent releases to support their innovations and business plans. Developers and entrepreneurs in that camp have expressed exasperation that Joyent hasn’t driven multiple releases.

Their criticism of Joyent has been frequent and eloquent, but ultimately neither side has a monopoly on the truth. Joyent feels justified in its caution by the “sequence of unfortunate events” around the multiple faulty efforts to roll out a release over the last year, which would have led to chaos had it reached the user base. After all, Node.js is a platform, not a library, and it needs to be managed conservatively.

All this -- the corporate politics, firebrand developer outbursts, and the rest -- convinces me that Node.js needs an independent foundation. Not that I’m a fan of creating open source foundations for every project -- putting your project into a nonprofit rarely solves any problems, and most projects are better off joining an existing organization.

The creation of a government-recognized nonprofit has been historically important in open source for two purposes:

1. As an imprimatur of “openness” by an otherwise proprietary activity by a single company that happens to involve open source code
2. As a way to sandbox the politics of business from the practicalities of development, creating a neutral venue for genuine collaboration among peers

In that first role, the problems remain, even if they are masked by the veneer of a nonprofit. The second role needs a firm base of collaboration before it is put in place. Foundations don’t solve problems, but they make solutions permanent once they are put in place. Solve problems first, make a foundation afterward.

 

Node.js needs a foundation to supervise it. Its community is probably already large enough to render the idea of joining an existing community such as Eclipse or Apache inappropriate. But is the proposed foundation the right answer? Bill Scott of PayPal said at the Node Summit that PayPal is supporting the foundation, but watching the community. That seems to me to be the right balance.

What’s being proposed so far is a pay-to-play corporate trade association in the image of the Linux Foundation, with large, non-revenue-linked fees to scare away the startups and rules drawn up by big corporate participants like Microsoft and IBM. This is surely not the right answer to bring io.js partisans back into the fold. The bitter politics around Node.js certainly needs sandboxing, but so does the desire of developers to drive the agenda. A working Node Foundation will need both the operations-respecting release cadence Joyent seeks and the dynamic R&D space that io.js entrepreneurs desire.

A model like that used by Eclipse might work better here. After years of evolution, Eclipse now has a set of appealing governance features for this situation, notably pay-for-play fees that also require commitment of developers to the project and strict boundaries between fiduciary and technical governance. Eclipse also requires donation of the trademark to the foundation, a step neglected by projects at their peril if they are to avoid future exploitation by the trademark holder.

Of course, this all may be in vain; a crucial control point for Node.js, its package manager NPM, is controlled by a startup company of the same name. Divisive politics could recur unless that's dealt with as well. It seems the Node.js community, not only Joyent, has its work cut out for it.

This story, "Untangling the intense politics behind Node.js" was originally published by InfoWorld.

Android Users Can Now Message In Local Language With Ease!

Android users of Indic languages have a reason to rejoice. Indic languages will take a new step in the digital world with a new Indic keyboard coming in, that supports 11 languages, allowing the consumers to download local language keyboards for their mobile devices.

Developed by developer collective Swathanthra Malayalam Computing , the Indic keyboard has crossed 100,000 downloads. It is worth mentioning here that Google's Hindi keyboard has already witnessed 10 million downloads. Similar traction is seen for other language keyboards like Kannada.

Speaking about the keyboard, Vishal Anand, chief product officer at news app Newshunt said, “We are seeing beginnings of content creation phase. As more people start writing more keyboards will get more intelligent and better.”

We have seen that attempts to increase local language penetration on desktop have proved not so successful. But this attempt of local language input methods or ways of typing into a computing device, has lead to promotion of more local language content. It will also lead to a 'virtuous cycle' of local language adoption. Anand said, “Indic language is going through the same evolution that western languages went through.” The new Indic keyboard was built by Jishnu Mohan, a member of Swathanthra Malayalam Computing. 

Top 10 Countries For Software Engineers

 IT has been the fastest growing industry in past few years. There are number of jobs available in IT. You can play any role. If you are a software engineer, we have listed top ten countries where you can work. The list is based on the survey of highest median earnings of software engineers, cost of living in these countries and happiness index. 

1. Switzerland


Average pay scale for software engineer - $104200
‘Happiness Index’ Rank - 6
‘Best for workers: countries’ Rank - 24

2. Norway


Average pay scale for software engineer - $81400
‘Happiness Index’ Rank - 3
‘Best for workers: countries’ Rank - 6

3. United States


Average pay scale for software engineer - $76000
‘Happiness Index’ Rank - 16
‘Best for workers: countries’ Rank - 7

4. Denmark


Average pay scale for software engineer - $71500
‘Happiness Index’ Rank - 1
‘Best for workers: countries’ Rank - 4

5. Israel


Average pay scale for software engineer - $70700
‘Happiness Index’ Rank - 10
‘Best for workers: countries’ Rank - 10

6. Australia


Average pay scale for software engineer - $65900
‘Happiness Index’ Rank - 8
‘Best for workers: countries’ Rank - 14

7. Germany


Average pay scale for software engineer - $63800
‘Happiness Index’ Rank - 27
‘Best for workers: countries’ Rank - 20

8. Sweden


Average pay scale for software engineer - $61400
‘Happiness Index’ Rank - 5
‘Best for workers: countries’ Rank - 8

9. New Zealand


Average pay scale for software engineer - $59600
‘Happiness Index’ Rank - 17
‘Best for workers: countries’ Rank - 8

10. Canada


Average pay scale for software engineer - $57500
‘Happiness Index’ Rank - 2
‘Best for workers: countries’ Rank - 11