Developer, PHP

Php Developer Dubai

PHP Developer In Dubai

Php development trend in dubai

Trend in Information technology in world is not certain. We can say that it is up-growing in world. Same as in United Arab Emirates. Inside UAE, dubai is one of the open market in MENA. PHP developer in Dubai are concerned and regularly seeing trend of PHP in Dubai.

Developers in PHP are growing in dubai. Developers group based on PHP are increasing day by day. We can not say that, all are satisfied with Job title PHP developer, PHP engineer but as a developer from south Asia, we are getting opportunity in programming field.

Web development solutions based in php

Dubai Client are not meeting people who can really give solutions of their requirement in comparison with requirements. Clients are facing problem with half way stuck in projects. They are not getting the results so far.
Want To Contact PHP Developer Dubai Based ???
Please go to contact page for any web based solutions in dubai concerned with topic php. I will give solution by myself or by any mean.

PHP Developer Job Search website

Getting Job in dubai is not so easy but if you follow the track and you have hand on experience, you are likely to get Job. Do not miss the job websites regular application, meetup, newspaper etc.
Most important thing is to be target with your field of requirement.
If you need any help please contact me. Of course suggestions and guidelines are for free.
You have to go with following links for job hunt. PHP developer are always in demand inside dubai.
For this, you have to roam around these sites and more

dubizzle.com

bayt.com

PHP Dubai developer Meetup

Meeting people related to your field is important in career. If they do not lead you, they will give way to walk. Even if they do not give it, you will have idea to achieve those things. For this things, Meetup in PHP where PHP developer gets engaged will be good for introducing you in dubai.

Here are some links you can visit or connect for meetup and communication.

meetup.com

thecribb.co

Be the First to comment. Read More
AngularJS, Developer, JavaScript, Node.js

Getting Started with the MEAN Stack

If you are here you are probably starting a new project from zero. Usually start developing on the mean stack without a framework but only with an empty folder can be frustrating. There is valid alternative out there like MEAN.io and the MEAN.js framework but using this framework can be too much for a simple code test and usually it put a lot of useless things in the pot.

To better understand how things work in a MEAN stack the best way it to build the stack from zero. In this tutorial we will create the most basic mean application you can immagine. The good thing of this stack is the modularity and expandibilty given from npm and bower.

Assuming you have already installed NodeJS and MongoDB on your development machine let start creating the empty folder for the project. Into the folder create a first file called package.json.

 
{
  "name": "propoudel-mean-seed",
  "main": "server.js",
  "dependencies": {
    
  }
}

We have added zero dependencies because we want to use the latest version of any package and we want to use npm to get it from it repository. First of all we will install all the necessary package, then we will configure the it to work together.

npm install mongoose –save

npm install express –save

npm install body-parser –save

npm install method-override –save

Now that we have all the needed modules in place we can start working on the server side
of the stack, setting Node,Express and the connection to the Mongo database.

 

The Server

The folder structure of the application is shown in the picture, this is not the best of all structure, it’s just one of the possible. Once you will get confident you can change it to better suite your needs.

The first file we will edit is the db.js into the config folder. This file will contain only the info for the database connection.

 

 

//config/db.js
 
module.exports = {
    url : 'mongodb://localhost/basic-mean-dev'
}

With the config file for DB in place it’s time to create the most important file : server.js . In this file we will load and set all the modules of the application then we start the HTTP server.

 

 

Below the content of the server.js file :

// server.js
 
var express        = require('express');
var app            = express();
var mongoose       = require('mongoose');
var bodyParser     = require('body-parser');
var methodOverride = require('method-override');
 
    
// config files
var db = require('./config/db');
 
// set our port
var port = 3000; 
 
// connect to  mongoDB  
mongoose.connect(db.url); 
 
// parse application/json 
app.use(bodyParser.json()); 
 
// parse application/vnd.api+json as json
app.use(bodyParser.json({ type: 'application/vnd.api+json' })); 
 
// parse application/x-www-form-urlencoded
app.use(bodyParser.urlencoded({ extended: true })); 
 
// override with the X-HTTP-Method-Override header in the request. simulate DELETE/PUT
app.use(methodOverride('X-HTTP-Method-Override')); 
 
//set the public folder of the app
app.use(express.static(__dirname + '/public')); 
 
//load basic route for server
require('./server/routes/basic')(app); 
 
// startup our app at http://localhost:3000
app.listen(port);               
 
// shoutout to the user                     
console.log('Server available at http://localhost:' + port);
 
// expose app           
exports = module.exports = app;

At this point our server is ready to be started but we didn’t create any page to show in the public folder. Let’s create the most basic index.html like

Server ready

and start the server with

node server.js

to see if all the work made till now was done correctly.

As the name of the task suggest we miss a piece in our puzzle, AngularJS. In a mean stack application AngularJS is responsible of the frontend of our application. All the controller, service, directive of the AngularJS application will e developed in the public folder. The connection with the db and most in general with the server will be made via REST call to the server application.

To get the frontend library we are going to need we will use bower as package manager. To maintain a good structure of the application we want to execute bower from the main directory and place the lib into the public folder. We need a .bowerrc cnfiguration file :

 

 
{
  "directory": "public/bower_components",
  "storage": {
          "packages": ".bower-cache",
          "registry": ".bower-registry"
  },
  "tmp": ".bower-tmp"
}

And a bower.json file where all the components will be listed

 
{
  "name": "propoudel-mean-seed",
  "dependencies": {
    "angular": "latest",
    "angular-route": "latest"
  }
}

For the purpose of this tutorial we want to mantaing things simple.

bower install

Now the file for the AngularJS frontend is loaded in the public/bower-components folder. Import it in the index.html and we are done. A more complete index.html page :

 

<!DOCTYPE html>
<html lang="en" ng-app="myApp" class="no-js"> <!--<![endif]-->
<head>
  <meta charset="utf-8">
  <meta http-equiv="X-UA-Compatible" content="IE=edge">
  <title>Getting start with MEAN</title>
</head>
<body>

	<h1>{{"AngularJS is working"}}</h1>
  
  <script src="bower_components/angular/angular.js"></script>
  <script src="js/app.js"></script>
</body>

As you can see in the index.html we imported the app.js file that we didn’t create. This file will be the entry point of the AngularJS application and need to be placed in the public/js folder.

angular.module('myApp', []);

Now if you restart the server again and browse to http://locahost:3000 , if all things was made well you will see the classic AngularJS is working message.

 

Be the First to comment. Read More
AngularJS, Developer, Durpal, Ecommerce Development, Java, JavaScript, Magento, Magento 2, MySql, Node.js, Paypal, PHP, Symfony, WordPress, Zend Framework 2

Mistakes to Avoid With Responsive Web Design

Nowadays, when it seems like everyone has a smartphone or tablet, the importance of creating mobile friendly websites cannot be overstated. As a result, business owners have lapped up the idea of responsive web design because it can give a complete experience to users on different platforms – from desktop computers to smartphones to tablets. Creating a website with responsive design makes sense because it works across different devices and as a result you saved money on developing different websites for different platforms.

But, to make the most out of responsive web design, there are some mistakes you need to avoid.

 

Don’t Design for Desktop First

One of the common mistakes people make is design a website for desktops first because they think it will be easy to turn it into a responsive design for other devices. But this mistake during the planning stage itself can become a huge issue for you. It can cause rework and errors can creep up too.

It might seem time consuming or difficult to create websites for mobile devices first. This is because it can force you to make trade-offs on what content to include and to think in a way you are not used to. However the content and design on the whole will be a lot better. As a rule of thumb you can start with smaller devices first. Once you have the right design for mobile, it can be easily adapted for bigger screens.

 

The Trouble with Navigation Menus

When designing for mobile, the problems with navigation design can become the bane of your existence and have to be avoided. Unlike fixed width designs, navigation for responsive design should be done according to the device type (so your smartphone navigation may differ from your tablet navigation and still differ from the desktop navigation).

Many designers find themselves overwhelmed by task of trying to create a navigation menu that works across all screens. In many cases designers struggle to convert horizontal list menus to vertical list menus, especially to fit smaller mobile screens. However, since the navigation menu is not designed according to the screen, it can create a poor user experience.

 

Content Shouldn’t be Hidden

Responsive designs generally have less space for pictures and content but that doesn’t mean your content should be neglected. You will have to re-arrange it in a way that it can be read easily. You can easily do that by creating navigation links using anchors that can lead users to the content they have been looking for on the page. Those who hide content using CSS need to realize that the content still gets downloaded, hence you have nothing to lose by giving users a complete viewing experience. Quite simply, users should not be penalized for the device they use.

 

Separate Mobile URLs

Having a separate URL for your mobile site can be a complete disaster and, arguably, defeats the whole purpose of a responsive design in the first place. Users end up wasting precious time as they are redirected from the website to its mobile version. Moreover it can seriously hurt your search engine rankings too. But, of course, there are some benefits to having different URLs. It ensures that you can construct mobile sites with lighter pages that perform better on smart devices. The site will be more catered for viewing on specific platforms as well. Unfortunately, the negatives of having separate mobile URLs outweigh the positives.

 

Creating Poor Mobile UX

You cannot simply compress content meant for desktop into a mobile version; doing that will affect the viewing experience for your users, who will be put off. It is important that you create an appropriate user interface to work within the constraints of space of mobiles. You can use strategies such as using dropdown menus in place of navigation bars that are used in desktop versions as this will save you space. If you design for mobile first, this usually isn’t an issue.

 

Don’t Disregard Cross-contextual Conventions

When you are working on responsive design, you can’t just think of desktops and mobile devices because there are many other devices that have to be factored in. People may be visiting your site from Internet-enabled smart TV’s or set top boxes that contain a brower. Even tablets come in a wide array of form factors nowadays. But that doesn’t mean you have to create an indigenous user interface for all devices – you would be better off creating different websites. What you can do is create responsive navigation that keeps the context of the device in mind and creates a design that’s easily understandable to users.

 

Don’t Ignore Page Load Times

With the pervasive access to broadband on desktops, web developers have gotten used to including relatively large resources on their web pages. However, when dealing with mobile, our users may often be on slow and limited 2G and 3G connections. Also keep in minf international users who often have to pay based on the amount of bandwidth they use.

The point is, even though a page may load easily on a desktop, it could potentially take a long time on mobile devices or use excessive, and pricey, bandwidth. To makes matters worse, when users are forced to wait, even if only for a few seconds, on their device for a site to load, they will often leave the page and thus you will lose your mobile traffic.

 

Not developing for Touchscreen devices

Most handheld devices today use a touchscreen. Even many laptops are now coming touch-enabled. Hence it’s important that when you are creating a responsive design that you don’t overlook the importance of handling touch. There are two aspects to this: the first is that clickable items, such as buttons, take into account the size of a user’s finger (don’t make the user have to zoom to click); the second is that you properly handle touch events (doing so can also overcome the 300ms delay for click events that still exists on some devices).

 

Conclusion

These are few simple mistakes that often happen because of oversight. If you manage to steer clear of them you will ensure that your responsive design works well across all types of devices and makes its mark.

Be the First to comment. Read More
Android, Developer, iOS

7 Things to Consider When Making iOS and Android Apps with Cordova or PhoneGap

The promise of PhoneGap/Cordova development is quite alluring. Use your existing HTML/JS/CSS skills (and team) to build cross-platform mobile applications for iOS/Android, and other mobile platforms. As a bonus, you can then update your existing codebase once for all platforms instead of maintaining separate repositories (or paying specialized developers). This post will talk about some of the questions and decisions you should consider before beginning your next cross-platform Cordova project.

 

Cordova or PhoneGap?

This first choice might be a confusing one but it’s really very simple. PhoneGap is a product owned by Adobe which currently includes additional build services, and it may or may not eventually offer additional services and/or charge payments for use in the future. Cordova is owned and maintained by Apache, and will always be maintained as an open source project. Currently they both have a very similar API. I would recommend going with Cordova, unless you require the additional PhoneGap build services.

 

Which plugins will you use?

Plugins are a big part of the magic of Cordova development. Cordova ships with a minimal set of APIs, and projects add what extra APIs they require through plugins. You can search through all existing plugins using the Cordova Plugin Registry. The core set of “blessed” Cordova plugins provide access to Battery, Camera, Dialogs, Geolocation, and more, which are generally available across all supported platforms.

There are also many other third party plugins that allow extra functionality including native sharing, analytics, and many other platform and device-specific capabilities, however cross-platform support is typically more limited with third-party plugins. Make sure that you are aware of which plugins you will need and make sure that they are available on the platforms and versions you will be supporting. (Note: Cordova and PhoneGap use the same plugins.)

 

Which platforms and versions will you support?

For the most part it is trivial to support iOS6, iOS7, and iOS8, and Android 4.4 (KitKat, version 19), with Cordova-blessed and third-party plugins, and modern-browser-friendly HTML5 and CSS3. As an aside, both the Facebook and Twitter iOS apps only support iOS 6 and later. It is not as easy to support iOS5 and earlier as these versions have been deprecated in Cordova as of version 3.5.

The first generation iPad is locked at version 5.1.1, so those iPad users (and users who have not updated beyond iOS5) will not be able to download your app from the App Store unless you customize the application in XCode. Additionally, if you are going to support 64-bit iOS devices such as the iPhone 5S, you will either need to use a recent version of Cordova (3.5 or greater), or you will also need to do some further customization within XCode.

Support for legacy Android versions is a bit more complicated, depending on what your specific needs are. You will want to be familiar with the Android Developer dashboard for weekly updated stats about Android platform versions. Android versions 2.2 (Froyo, version 8) and earlier do not have Play Market, so those users won’t download your app. Android version 2.3 (Gingerbread, version 10) is officially warned against using in the Cordova Security Guide, and many third-party Cordova plugins do not support Gingerbread, so its use is discouraged. Android 3.x (Honeycomb, version 11-14) appears to have been completely phased out with zero percent of users in the weekly dashboard (so testing this version might be both complicated and completely worthless).

As far as worthwhile Android versions go, version 4.4 (KitKat, version 19) has excellent CSS3 & HTML support. You can most likely just build your working iOS Cordova app for android and view it in a 4.4.x version Android device and not have any issues at all. Versions 4.0 – 4.3 (Ice Cream Sandwich and Jelly Bean, versions 14-18) will likely require at least a little more effort, especially if you are using hardware-accelerated CSS 3D transforms or scrollable divs. You will probably spend the majority of your UI bug-fixing time working on these versions alone, however at the time of this writing, these versions (not including KitKat) enjoy a combined 63% global distribution, so this is time well spent in most cases.

Regarding CSS and platform support and version fragmentation, one approach that I recommend is similar to that used by Modernizr. You can use the Cordova device plugin to detect the OS and version (and other device-specific properties), and append specialized classes to the html or body elements, such as ‘ios’, ‘android’, and ‘jelly-bean’. This way you can target specific versions with CSS more easily. Another variation on this approach is to add a class such as ‘legacy’ for certain platform versions, to simplify the CSS selectors while still allowing for similar platform/version differentiation.

 

What form factors will you consider?

Will you support only mobile phone or tablet form-factors, or provide a responsive, universal experience? This question can dramatically change your designer, developer, and tester resource requirements for a given project. Just as each platform and platform version will introduce an extra level of effort, each form-factor/breakpoint setting will introduce a new level of effort for designers and developers.

Additionally, each level of effort for designers/developers will create a new level of effort for testing requirements for each platform version. That is to say that for a project with three supported versions with two identical form-factors, there are two levels of designer/developer effort and six levels of testing effort involved.

 

What about offline support?

What is your app going to do when there is no internet connection? While some apps don’t require any internet access for normal behavior (e.g. a calculator), some do. Take a moment to consider the user-experience for your app when no internet connection is present. Things that might not work while offline include sharing, linking (includes opening links in an in-app browser), analytics, and file access/transfer (ajax or otherwise). You can use the Cordova Network/Connection plugin to detect the connection type and to handle online and offline detection and event handling.

 

Are you handy with XCode and Eclipse?

There will probably be some things that you will not like about the out-of-the-box Cordova XCode implementation. For example, do you want the status bar to be hidden when you launch the app (and/or after the start screen)? Do you want to disable Universal application status? You might even want to customize some Cordova application settings or plugins (which are written in Objective-C). If you want to release your application to the App Store (or do some of the things just mentioned), then at some point you are going to have to learn some basics of XCode development. Most of the Android settings can be changed directly in the AndroidManifest.xml file so knowledge of the Eclipse IDE isn’t as essential, however you should be aware of how to sign and publish a Cordova app for Android.

 

How will you test the app?

It is a good idea to have one or two physical devices for each platform/version combo you are supporting. There are emulators and simulators that can help you to identify some major issues, but nothing beats having a real device for testing. With emulators sometimes you will get false positives or negatives for bugs (and sometimes the emulators have bugs of their own which don’t affect your application). It is also helpful to be aware of the any specific bugs and/or issues with the platforms/versions/devices you are testing.

Debugging Cordova applications can sometimes be a challenge, but if you are familiar with Chrome and Safari Dev Tools it is much easier. For Android devices, you should be able to choose Tools > Inspect Devices and have full access to your application’s HTML, CSS and JS. Similarly in iOS once debugging is enabled in iOS Safari and Mac Safari, you will have access to the Developer Panel with similar access (although with a very XCode-style debugging UI which might take some getting used to). You will need to reopen the Safari Developer panel whenever you restart your app, which can be a pain, but you can also simply reload the app with Command+R instead. Another approach I’ve used is to use setTimeout or an alert to delay the app for debugging so that I have time to open the console before the application starts up.

Hopefully this post will help you to think about the considerations for in-house cross-platform packaged application development with Cordova/PhoneGap. Mobile application development typically involves a lot of testing and iteration, so be sure to plan accordingly.

Be the First to comment. Read More