Custom projects and current projects customization’s
you can ask for custom projects by just simply contacting me
Institute Management system customization’s can be estimated through the following link
Estimate Now
Information Technology Problem Solving – The 6 Principles of Scientific Problem Solving
This paper will explain a scientific approach to problem solving. Although it is written to address Information Technology related problems, the concepts might also be applicable in other disciplines. The methods, concepts, and techniques described here is nothing new, but it is shocking how many “problem solvers” fail to use them. In between I will include some real-life examples.
Why do problem solvers guess in stead of following a scientific approach to problem solving? Maybe because it feels quicker? Maybe a lack of experience in efficient problem solving? Or maybe because it feels like hard work to do it scientifically? Maybe while you keep on guessing and not really solving, you generate more income and add some job security? Or maybe because you violate the first principle of problem solving: understand the problem.
Principle #1. Understand the *real* problem.
Isn’t it obvious that before you can solve, you need to understand the problem? Maybe. But, most of the time the solver will start solving without knowing the real problem. What the client or user describe as “The Problem” is normally only the symptom! “My computer does not want to switch on” is the symptom. The real problem could be that the whole building is without power. “Every time I try to add a new product, I get an error message” is the symptom. Here the real problem could be “Only the last 2 products I tried to add gave a ‘Product already exists’ error”. Another classic example: “Nothing is working”…
You start your investigation by defining the “real problem”. This will entail asking questions (and sometimes verify them), and doing some basic testing. Ask the user questions like “when was the last time it worked successfully?”, “How long have you been using the system?”, “Does it work on another PC or another user?”, “What is the exact error message?” etc. Ask for a screen-print of the error if possible. Your basic testing will be to ensure the end-to-end equipment is up and running. Check the user’s PC, the network, the Web Server, Firewalls, the File Server, the Database back-end, etc. Best-case you will pint-point the problem already. Worst-case you can eliminate a lot of areas for the cause of the problem.
A real life example. The symptom according to the user: “The system hangs up at random times when I place orders”. The environment: The user enters the order detail on a form in a mainframe application. When all the detail is completed, the user will tab off the form. The mainframe then sends this detail via communication software to an Oracle Client/Server system at the plant. The Oracle system will do capacity planning and either returns an error or an expected order date back to the mainframe system. This problem is quite serious, because you can loose clients if they try to place orders and the system does not accept them! To attempt to solve this problem, people started by investigating: 1) The load and capacity of the mainframe hardware 2) Monitoring the network load between the mainframe and the Oracle system 3) Hiring consultants to debug the communication software 4) Debugging the Oracle capacity planning system After spending a couple of months they could not solve the problem.
The “Scientific Problem Solver” was called in. It took less than a day and the problem was solved! How? The solver spends the day at the user to see what the “real problem” was. It was found that the problem only occurs with export orders. By investigating the capture screen and user actions, it was found that with export orders the last field on the form is always left blank and the user did not tab off this field. The system was not hanging, it waited for the user to press “tab” another time. Problem solved. It can be noted that the “Scientific Problem Solver” had very limited knowledge of the mainframe, of the order capturing system, of the communication software, and of the Oracle capacity planning system. And this brings us at Principle#2.
Principle #2. Do not be afraid to start the solving process, even if you do not understand the system.
How many times have you heard “I cannot touch that code, because it was developed by someone else!”, or “I cannot help because I am a HR Consultant and that is a Finance problem”? If you washing machine does not want to switch on, you do not need to be an Electrical Engineer, Washing Machine Repair Specialist, Technician, or whatever specialist to do some basic fault finding. Make sure the plug is working. Check the trip-switch, etc. “I have never seen this error before” should not stop you from attempting to solve. With the error message and an Internet Search engine, you can get lots of starting points.
In every complex system there are a couple of basic working principles. System A that reads data from System B can be horribly complex (maybe a Laboratory Spectrometer that reads data from a Programmable Logic Computer via an RS-232 port). But, some basics to test for: Does both systems have power? Is there an error message in the event log on one of these systems? Can you “ping” or trace a network packet from the one system to the other? Try a different communication cable. Search the internet for the error message.
Once you have established what the problem is, you need to start solving it. Sometimes the initial investigation will point you directly to the solution (switch the power on; replace the faulty cable, etc). But, sometimes the real problem is complex in itself, so the next principle is to solve it simple.
Principle #3. Conquer it simple.
Let’s start this section with a real-life example. Under certain conditions, a stored procedure will hang. The stored procedure normally takes about an hour to run (when it is not hanging). So, the developer tried to debug. Make some changes and then wait another hour or so to see if the problem is solved. After some days the developer gave up and the “Problem Solver” took over. The “Problem Solver” had to his disposal the knowledge under witch conditions the stored procedure would hang. So, it was a simple exercise to make a copy of the procedure, and then with this copy to strip all unnecessary code. All parameters were changed with hard-coded values. Bits of code were executed at a time and the result-sets were then again hard-coded into the copy of the procedure. Within 3 hours the problem was solved. An infinite-loop was discovered.
What the “Problem Solver” did, was to replicate the problem and at the same time tried to isolate the code that caused the problem. In doing so, the complex (and time consuming) stored procedure became something fast and simple.
If the problem is inside an application, create a new application and try to simulate the problem inside the new application as simple as possible. If the problem occurs when a certain method for a certain control gets called, then try to only include this control in the empty application and call that method with hard-coded values. If the problem is with embedded SQL inside a C# application, then try to simulate the SQL inside of a Database Query tool (like SQL*Plus for Oracle, Query Analyzer for SQL Server, or use the code in MS Excel via ODBC to the database).
The moment you can replicate the problem in a simple way, you are more than 80% on your way to solve it.
If you do not know where in the program the problem is, then use DEBUG.
Principle #4. Debug.
Most application development tools come standard with a debugger. Weather it is Macromedia Flash, Microsoft Dot Net, Delphi, or what ever development environment there will be some sort of debugger. If the tool does not come standard with a debugger, then you can simulate one.
The first thing you want to do with the debugger is to determine where the problem is. You do this by adding breakpoints at key areas. Then you run the program in debug mode and you will know between which breakpoints the problem occurred. Drill down and you will find the spot. Now that you know where the problem is, you can “conquer it simple”
Another nice feature of most debuggers includes the facility to watch variables, values, parameters, etc. as you step through the program. With these values known at certain steps, you can hard-code them into your “simplified version” of the program
If a development tool does not support debugging, then you can simulate it. Put in steps in the program that outputs variable values and “hello I am here” messages either to the screen, to a log file, or to a database table. Remember to take them out when the problem is resolved… you don’t want your file system to be cluttered or filled up with log files!
Principle #5. There is a wealth of information on the database back-end that will help to solve a problem.
The “Problem Solver” was called to help solve a very tricky problem. A project was migrating system from a mainframe to client-server technology. All went well during testing, but when the systems went live, all of a sudden there were quite a few, and quite random “General Protection Faults”. (The GPF-error was the general error trap in Windows 95 and 98). It was tried to simplify the code, debugging was attempted, but it was impossible to replicate. In the LAB environment, the problem would not occur! Debugging trace messages to log files indicated that the problem occurred very randomly. Some users experienced it more than others, but eventually all users will get them! Interesting problem.
The “Problem Solver” solved this after he started to analyze the database back-end. Not sure if it was by chance or because he systematically moved in the right direction because of a scientific approach. Through tracing what is happening on the back-end level, it was found that all these applications were creating more-and-more connections to the database. Every time a user starts a new transaction another connection was established to the database. The sum-total of the connections were only released when the application was closed. As the user navigated to new windows inside the same application, more and more connections are opened, and after a specific number of connections, the application will have enough and then crash. This was a programming fault in a template that was used by all the developers. The solution was to first test if a cursor to the database is already open, before opening it again.
How do you trace on the back-end database what is happening? The main database providers have GUI tools that help you to trace or analyze what queries are fired against the database. It will also show you when people connect, disconnect, or were unable to connect because of security violations. Most databases also include some system dictionary tables that can be queried to get this information. These traces can sometimes tell ‘n whole story of why something is failing. The query code you retrieve from the trace can be help to “simplify the search”. You can see from the trace if the program makes successful contact with the database. You can see how long it takes for a query to execute.
To add to Principle#2 (do not be afraid to start…); you can analyze this trace information, even though you might not know anything about the detail of the application.
Remember though that these back-end traces can put a strain on the back-end resources. Do not leave them running for unnecessary long.
Principle #6. Use fresh eyes.
This is the last principle. Do not spend too much time on the problem before you ask for assistance. The assistance does not have to be from someone more senior than you. The principle is that you need a pair of fresh eyes for a fresh perspective and sometimes a bit of fresh air by taking a break. The other person will look and then ask a question or two. Sometimes it is something very obvious that was missed. Sometimes just by answering the question it makes you think in a new directions. Also, if you spend hours looking at the same piece of code, it is very easy to start looking over a silly mistake. A lot of finance balancing problems get solved over a beer. It could be a change of scenery, and/or the relaxed atmosphere that will pop out the solution. Maybe it is the fresh oxygen that went to the brain while walking to the pub. Maybe it is because the problem got discussed with someone else.
Conclusion
After reading this paper, the author hope that you will try these the next time you encounter a problem to solve. Hopefully by applying these six principles you will realize the advantages they bring, rather than to “guess” your way to a solution.
Avoid the Cyber Threat by Using a Safe Programming Language
The Problem
Since the existence of networked, automated information systems, the so-called “Cyber-Threat” has been known to be a major security and business continuity risk. One of the very first worms, the “Morris-Worm”, destroyed the e-mail infrastructure of the early internet. The Cyber Threat is not thoroughly understood even by many executives of the software industry, and the situation amongst the software user community is even worse. An Asian nation-state actor recently subverted the Google Mail login system by exploiting a weakness in internet explorer used by Google employees. The same Asian nation state is also suspected to have illegally downloaded the full design blueprints of the largest European jet engine manufacturer.
The Cyber Threat is real and may have grave long-term consequences for those at the “receiving end” of a cyber attack.
The Solution
Unfortunately there is no “silver bullet” solution to this problem. Rather, a holistic solution comprising technology, business processes, user education and security rule enforcement must be employed to properly secure valuable data. The determined support of the CEO, CIO and CFO is clearly required to achieve that. CFOs understand that there exist strategic business risks, which are very difficult to be quantified in monetary terms, but they know that these risks might kill the whole business if left un-addressed. For example, criminal accounting practices of mid-level managers could kill any company, so the CFO will have to ensure the books are regularly audited by an independent authority. The same amount of diligence will be required to secure the confidential data of companies against the Cyber Threat.
This article is about a key aspect of defending against the Cyber Threat – securing software. It is important to note that, again, there is no “silver bullet” to secure a critical software system, but many of today’s security flaws (such as “Buffer Overflow Exploits”) could be avoided simply by using a Safe Programming Language. This kind of programming languages will make sure that low-level Cyber Attacks are automatically thwarted by the system infrastructure.
What is a “Safe Programming Language”?
As with many subjects in information technology, there is no authoritative definition of the term. Salesmen and consultants bend the term to suit their needs. My definition is simple: A Safe Programming Language (SPL) assures that the program runtime (such as the heap, stack or pointers or machine code) cannot be subverted because of a programming error. An SPL will make sure that a process will immediately terminate upon detecting such a low-level error condition. The Cyber Attacker will not be able to subvert the program runtime and “inject” his own, malicious program code. The programmer can then inspect the “remains” of the terminated process (such as a core file) in a useful manner to analyze and rectify the programming error.
Examples of Safe Programming Languages (in alphabetical order): C#, Cyclone, Java, Sappeur, SPARK Ada, Modula-3, Visual Basic.Net
Examples of Unsafe Programming Languages (in alphabetical order): Ada, Assembly Language, C, C++, Fortran, Modula-2, (Object-)Pascal
What should I do as a Programmer?
Whenever you start a new software development project, select a Safe Programming Language, instead of chosing the “industry standard” of unsafe languages like C or C++. There exist high-performance languages like Cyclone, Modula-3 and Sappeur, which can compete with C/C++ in terms of memory and processing time requirements. Don’t think that you are “one of the few programmers who can write bug-free code”.
Windows Phone App Developers Are Being Ignored
App development is currently a multi-billion dollar global industry. Apple, for example, is estimated to have made around $3.2 billion in app revenue alone from the contents of its app store. Finding new applications and writing the software is one of the few industries currently working at full stretch. Microsoft is racing to fill its app store with products.
Given this virtual gold rush, you might expect app developers to be keen to find and hire bright young software engineers. All the more surprising then to find on a LinkedIn Group devoted to Windows Phone development a chorus of complaints from talented developers about their inability to find work.
Thomas Mullen is an experienced Windows Phone and Windows 8 App developer who has started his own software business in Los Angeles. Despite his own success, Mullen asked publicly, ‘How many Windows Phone developers have published apps on the marketplace, but continue to be turned down for positions?’
‘When I wrote the question’ says Thomas,’ I wanted to hear if other people were getting the same responses from employers that I was. I wanted to know if any companies out there were listening and could give feedback on whether I should concentrate my efforts on developing my portfolio or should I just get to know as many people as I can and maybe someone can recommend me for the job? In this era of “WorkNumber”, most companies frown upon personal/professional references and will only verify that you worked at a company. So, that’s why I have built my portfolio around each program that I do highlighting a specific aspect of Windows Phone or a technology.’
Thomas’s question provoked a whole string of responses from the developer community – many agreeing with him.
Ron Gramann is a UK software engineer. Ron comments, ‘Here in the UK, when applying for WP contract work, it is expected that you have at least one app in the Store. Most of my WP work has been done as an independent. My last contract involved some WP prototyping, but nothing that went into production.’
‘The WP market today reminds me of ASP development in the 90s. Many of people involved are creatives, and are looking for someone to pick up the technical work. My interviews have been odd, like low-level obscure technical questions that really have nothing to do with phone development. Which makes me think the approach is “We’ll ask the hardest questions we can find… that’ll do it.” Which does not guarantee you’ll be a good phone developer.’
Interestingly, many of those responding have developed more than one Windows Phone app, but in their own time and for the love of it rather than on contract. Jeremiah Medina is a mobile developer in Denver. He says, ‘The problem in my neck of the woods is the lack of roles needing WP skills. WP is something I do in my spare time that I really enjoy. My day-to-day is a mobile web developer so in terms of just finding work there is no issue but I would love to do WP work full-time. I have three apps in the marketplace and plan a fourth so the lack of roles needing WP skills does not deter me from doing what I enjoy and love.’
Jason Barkley is a senior software developer in Fort Worth. He echoes Thomas Mullen’s complaint, ‘I had a situation with a WP7 opportunity where I didn’t even get an interview because I didn’t have a college degree. Of course, my philosophy on that is that any company so pretentious as to require a college degree before even speaking to me is a company for whom I wouldn’t enjoy working anyway.’
What does Thomas Mullen make of the responses to his question?
‘When it comes down to it,’ he says, ‘what do you need to break into this market? Everyone asks what version control system you used, or basic C++ questions that haven’t been used in Windows Phone. It’s almost as if they don’t have a clue about the people who haven’t worked on large projects or know the platform for which they are interviewing a candidate.’
‘I understand that many companies have existing products in iOS and Android and want people who can read code and translate code quickly to another language. But when you are hiring for a position which has a primary function of being in C# and WPF, knowledge of that should be expert and recent while knowledge of Android and iOS (C) should be secondary skills.’
‘Employers, from what I have experienced, are not looking for a degree, grades, or even what you have accomplished on your own. From what I have been asked in interviews, I can tell you that people are looking for “what has he learned from other companies that he can bring to us”. This is a good thing to look for as an added bonus in an employee, but it shouldn’t be the primary thing you are looking for in the interview.’
4 Lessons I Have Learned From Launching My Own Hedge Fund
In the first article of 2017, I would like to share with you a summary of what I have learned (and confirmed the knowledge I had) when building my own international hedge fund.
1. You need to reconcile with technical challenges
One of the most frustrating things I have encountered when creating my own hedge fund is the fact that there is something constantly malfunctioning. The technical equipment brings new challenges and even though I work with a team of excellent computer professionals, there isn't a single day without an error that needs to be fixed. The technology used for our hedge fund is really complex and challenging and, to my surprise, the process of fine tuning is as time demanding (or maybe even more) as the programming of all applications and algorithms. This is something, I was not ready for and I was hoping that now, when Elon Musk can repeatedly land space ships, it won’t be so difficult to make a couple of programs work together and assure that they all do what they are intended to. Well, I have a learned a lesson 🙂
Now I mention this point because sometimes I get an "anxious" email from one of my students that somewhere, somehow, an unexpected issue has just occurred and something that should have happened, did happen.
There is just one thing I can say about it – you need to accept that as part of ATS trading. Just as there are some features on my brand new (and expensive) car that sometimes don't work, there are also some technical challenges and weak moments in automated trading. In the past, I have lost some money due to these issues. Sometimes, I have "earned" by missing a trade that would have ended in a loss. But overall, due to these technical issues, I lost money. Still, I am here and trading. We live in the world where even an iconic iPhone isn't flawless – so don't expect that ATS trading will be without any technical issues. We have chosen a business where these things occur from time to time.
For me, the biggest lesson I have learned is: dedicate 2-3x more time for each step, to test and tune the programs, codes, technology, as these are all real, significant, challenges.
2. It is possible to build an interesting ATS for every futures market
This point is more positive – thanks to fully automated workflow, we manage to create a particularly interesting, strong and robust strategy for any future market. In some markets (like FESX) we are struggling with too low avg. trade value, and in others (like US T-bonds) with the fact that even a single tick of slippage (that has a value of 32 USD), can really affect the live trading results – and therefore in some markets you need to be really patient. There is one market that, due to the transaction costs, we keep failing in – and that is Nikkei (NK). But even here, we don't give up 🙂 Overall, we are doing pretty well in metals (GC, SI, HG) and also in energies (CL, NG, …). Even grains are suitable, but you should be careful here. Due to the recent general fundamental changes you need to build a system that trades both long and short. It is really a must. Furthermore, you should look for systems with symmetric results (ie long side has similar results to the short side).
3. You really need swing strategies in your portfolio
It is a fact. You can build an interesting and high-quality strategy for almost any futures market, but you cannot do it without swing strategies. For some markets, it is impossible to build an interesting intraday strategy. To reach higher diversification, swing strategies should be part of a portfolio. There is one more thing that needs to be considered for any hedge fund – there will be really big positions traded, which means that average slippage will be more significant (positions will be filled gradually at different prices) and therefore you should have really high ( resp. adequate) avg. trade value. Solely for this reason, it is a necessity to include swing ATS. But this applies also to smaller accounts (not only to hedge funds), when you want to be really diversified.
Good news is that it is not so difficult to build swing strategies and when you already have the workflow, the process isn't too much different from building intraday ATS. The workflow is the same, you only need to change a couple of details and experiment more with different approaches.
4. Hedge funds cannot be built and launched by a single person
You really need a team. Our fund consists of a 5-person team and I think that it is a bare minimum. The fund is such a demanding and complex entity, that really requires a team of specialists with specializations in different areas and you should leave the details up to them. Otherwise, it will drive you crazy. In our case, I have two highly talented programmers (one C #, JAVA, C ++, great database skills, etc., and the other mostly JAVA, great database skills; both having really deep insight in trading, both live ATS traders, and both having, of course, top EasyLanguage and TradeStation knowledge), one person focusing on client acquisition and law, one person for customer service, execution and overall CTA management, and myself – the author of all ideas and algorithms, also being a "General Manager ". The workload is constantly enormous and the first steps are really not simple, specifically to get it all running (especially when experiencing endless technical challenges). You really need to be enthusiastic about it, be passionate about it, and have the will to complete this challenge as you really need a lot of energy to complete such a demanding project. The good news is that it is possible – everything is possible when you follow your goals. Yes, in our case it has taken longer than I have expected, much longer, but on the other side, we won't miss anything. The opportunities have always been here and they always will be – every day. It is important to have really robust and solid foundations (which is also something I teach in online courses).
These were today's suggestions and observations. I have learned, of course, a lot more than that – some of which I share with you in this series .
Have a great start of 2017 and happy trading!
Do You Need to Know Everything About Hybrid App Development?
Hybrid mobile applications are like any other applications you will see on your mobile. They get easily installed on your mobile device. You can look for these apps in the App stores. By using these apps, you can engage your friends via social media, play games, track your health, take photos and much more.
Hybrid mobile applications are developed using a combination of web technologies like CSS, HTML, and JS as same as websites on the internet. The major difference is that hybrid applications are hosted inside a native app which further uses a mobile platform’s WebView. Here, WebView is a chromeless browser window which is typically configured to run fullscreen.
In fact, hybrid mobile apps enable you to access various device capabilities viz. camera, accelerometer, contacts, and much more. However, inside mobile browsers don’t allow you to access these capabilities from it. Furthermore, hybrid mobile applications include native UI elements in those situations where it is necessarily required, as proved by Basecamp’s approach towards hybrid mobile application development.
It is not easy to answer the question how a mobile app is built. Similarly, hybrid mobile apps are no different. A well-written hybrid application should not behave or look any different than its native equivalent. However, users don’t care about it as they only want an app that works well. It is what actually matters to them. If you are trying to figure out whether a mobile application is hybrid or native, it would be like you are trying to differentiate rare grape varieties of wine.
Unless you are the one who really cares about this, it is not terribly important. What all matters are how your hybrid mobile application development is going to work in the long run as no one will care about how it was built. A hybrid mobile application is said to be good if it performs well for its users.
How are hybrid mobile applications built?
Like other websites are built, hybrid mobile apps follow the same manner. Both are built with a combination of technologies like CSS, HTML, and JS. Generally, a hybrid app targets a Web View which is hosted inside a native container rather than targeting a mobile browser. This allows its users to access various hardware capabilities of the mobile device.
Many hybrid mobile apps today leverage Apache Cordova, a simple platform that consists of a set of JavaScript APIs for accessing mobile device capabilities through plug-ins that are built with native code. These plug-ins include APIs in order to access the device capabilities like contacts, accelerometer, camera, and more. In fact, a huge number of plugins are built and maintained by mobile app developers community-at-large which is can be found in the Apache Cordova Plugins Registry. A group of plugins that have been properly tested, documented, and extended can be found at the Telerik Verified Plugins Marketplace.
If we talk about Apache Cordova, it was actually started as a project named PhoneGap. But nowadays, PhoneGap is considered as a distribution of Apache Cordova which includes additional tools. To know more about its history, you can check out Cordova, PhoneGap and what’s in a name?
Various application assets like CSS, HTML, JS are packaged via tooling through Apache Cordova for targeting platform SDKs. Once a hybrid app is built, it can be run just like any other app on the mobile device. Apache Cordova provides the tooling that is highly driven by a command line interface. However, mobile app developers can still leverage IDEs such as Visual Studio and effective solutions like the Telerik Platform to further increase productivity.
Since mobile app developers don’t want to be getting locked into proprietary platforms, so hybrid mobile apps give a way to mobile app developers for re-using their existing skills in web development. This mainly includes SDKs provided by platform vendors and the programming languages.
Hybrid mobile app development somehow looks appealing to a company’s bottom line such as Why hire a developer for each platform when you can hire one developer and target all of them through CSS, HTML, and JavaScript? But, the reality is actually a bit more complicated to accept.
Obviously, it’s true that mobile app developers become able to target multiple platforms with hybrid mobile app development. But when it comes to WebView or web runtime, each platform comes with a set of caveats. This is more true for Android and not consistent between OS versions.
Furthermore, there must be some unique capabilities of platforms to which a mobile app developer may wish to target. In such cases, a combination of platform-specific code and plugins must be utilized which will take advantages of those capabilities. Optionally, mobile app developers can take advantage of 3rd party web runtimes such as Crosswalk which can be further embedded into your hybrid applications.
When should you build a hybrid mobile application?
It is the foremost concern of every mobile app developer who wants to build a hybrid mobile app. The first thing you should do is to check your mobile application’s requirements. Before committing to a platform strategy must evaluate the technical merits as well as non-technical merits of hybrid mobile apps over the web and native mobile apps. You should first consider the following questions before developing a hybrid app:
– What are the technical abilities of your mobile development team?
– Which mobile app platforms do you wish to target?
– Are you looking to use the multiple capabilities of the mobile device?
– Do you want to distribute your apps through the app stores?
– Does the hybrid approach really live up to its promise in the coming years?
The above questions are needed to be answered properly before the development of mobile apps. You may further evaluate more questions in detail.
WHICH MOBILE APP PLATFORMS DO YOU WISH TO TARGET?
You may have a number of choices if you want to target more than one platform. This is because the web offers a highly interactive solution for this purpose. However, the mobile browser is your target. HYbrid apps lend itself to this due to its reliance upon the WebView.
On the other hand, Native apps find a unique space among this. In fact, you are essentially coupled to this platform if you rely upon platform-specific programming languages and vendor SDKs. For this case, Objective-C or Swift is used for iOS, Java is used for Android and C# is used for Windows phone.
DO YOU WANT TO DISTRIBUTE YOUR MOBILE APP VIA APP STORES?
If you want to distribute your app via an app store, you must build a native or hybrid app. You can not distribute sites through app stores. Hence, browser’s address bar is provided for this. Despite this limitation, whether you build a hybrid or native app, it is strongly recommended that you must have a website available for your mobile app. You need to create this because this will be the first place your app users might expect to go in case if they stuck with any problem.
ARE YOU LOOKING TO USE THE CAPABILITIES OF THE MOBILE DEVICE?
As compared to native and hybrid apps, websites have a limited set of abilities. These limitations are put up by a browser that effectively sandboxing it from mobile OS. A lot more device capabilities are exposed through HTML5 with the help recent developments with mobile browsers which include geolocation, camera, and others.
In spite of these advancements, support for advanced functionality is still limited. For an instance, streaming and media capture are still unsupported in various mobile browsers. Due to these limitations with mobile browsers, there are many mobile app developers who are compelled to evaluate native and hybrid apps as alternatives. These platforms enable mobile app developers to access device APIs. While in case of hybrid apps, plugins support this capability.
It is often said that native app development is best suited for apps where graphics performance is paramount. The best example is the mobile games which completely rely on complex visual interactions on the screen. No matter, how wonderful game app you have developed for your users and how flawlessly it operates from a functional perspective, you can expect this game app to have a very low app store rating if it is lacking energy. Due to these reasons, mobile app developers have long argued for using a hybrid approach to build their game applications.
However, there exist a number of solutions for hybrid mobile apps. This includes WebGL and HTML5 Canvas that are well-suited to build game applications. In fact, these technologies are most preferred and approachable for mobile app developers due to the presence of libraries like EaselJS, Paper.js, and others. This is not limited to game development only. Developers build more traditional, line-of-business apps by using frameworks like Kendo UI and Famo.us.
WHAT ARE THE TECHNICAL ABILITIES OF YOUR APP DEVELOPMENT TEAM?
The team’s technical abilities is another major factor when it is about to evaluate development options for mobile. To build native applications, you need to hire developers who are proficient and experienced with the programming languages of every platform that you wish to target and platform SDKs. But for building web and hybrid apps, you need to hire developers who use web technologies like CSS, HTML, and JS. You may also have a team that can target more than one platform with a single set of technologies. So, this is a worth considering when you have to evaluate your opinions.
DOES THE HYBRID APPROACH REALLY LIVE UP TO ITS PROMISE?
Lastly, it is important to know that hybrid is not the be-all and end-all approach for mobile app development. At the initiation of this article, I have thrown light upon the challenges of overcoming the inconsistencies between WebViews. While other challenges still remain. With hybrid app development, you can target the various features of a mobile platform in order to discover if they are inaccessible. This is because plugins used for them can be unreliable, out-dated or missing altogether. This takes you to the dilemma whether to remove an application feature or to write the plug-in by yourself.
You may find hybrid app development model restricted when you have to develop an app that requires numerous native features or an app where performance is critically required for the success of the app. With this situation, you may found yourself to forcefully choose native development technologies. However, these are considered as alternative approaches which let you build performant native apps without having core knowledge of tools like Android Studio and Xcode.
Furthermore, the JavaScript-based NativeScript framework allows developers to build Android and iOS apps that forego the WebView for interactive and enhanced performance. NativeScript provides 100% access to Android APIs and iOS, removing the reliance on plugins which prove limitations while developing hybrid apps. But it is also not the be-all-end-all approach for developing native applications. However, this approach to application development is powerful which become more powerful with a higher learning curve. With NativeScript, you would not be using HTML to build UI. So, NativeScript is seriously considered by app developers if they have to develop an application with non-trivial performance requirements
The Genealogical Timeline of The Clarinet Family
The clarinet family are some of the most expressive instruments in any orchestra, woodwind ensemble, or jazz band. They have a very distinguishable sound spanning all of the ranges: low, medium, and high. We are so attracted to the sound of clarinets because they sound so much like us. The “licorice stick”, as it was once called, can express a full range of emotions from serious, happy, sensuous, exhilarating, sexy, dark, loving, dreamy, or melancholy.
The Beginning of the Clarinet Family
Clarinets were not invented, per se, but originally existed as folk shawms. Shawms can be dated back to the 1400 and 1500’s and were known in France as “bombardes” or “chalameux” and in Germany as “pommern”. They were slightly conical, had a narrow bore, 6 fingerholes, an open key inside a protective cylinder for the small finger, and a double reed like the oboe. In the late 1600’s the renowned woodwind maker Johann Christian Denner of Nuremberg turned the chalameux into the clarinet when he made them into the shape of an oboe.
Clarinets were the first reed instruments to have a cylindrical versus a conical bore and were made of boxwood. Wooden tubes were cut into several joints with a separate bell. Early clarinets were played with the reed tied to the mouthpiece with twine and against the player’s top lip, which often produced a shrill sound. It wasn’t until 1831 in Paris that the reed was switched to the lower lip providing for a more pleasant tone.
The first clarinets in the clarinet family had a key above the front holes to produce a’ and another key on the opposite side for b’ and were pitched in C. In 1720 Denner’s son modified the clarinets by moving the b’ hole towards the top. With the vent hole at the upper end of the cylinder, the scale of fundamentals could sound a 12th higher. The hole was covered by a speaker key. When the third key was added, the range was extended down a semitone to make it possible to play the missing b. During this time it was difficult to play in different keys, so the body of clarinets were divided into 3 sections so the player could use interchangeable joints of different lengths.
In 1750 the fourth (Ab, Eb) and fifth (F#, C#) keys were added and clarinets were no longer just solo instruments, but were now accepted into the orchestra. Further refinements came in 1790 when the sixth (C#, G#) key was added and the pear-shaped barrel disappeared. Although, the mechanics improved with the addition of keys, there continued to be ongoing difficulties with fingering, correct embouchere, and intonation, so different clarinets were made for playing sharp keys and flat keys. Finally in 1809 Iwan Muller developed the prototype of what became the modern Bb clarinet with 13 keys. In 1817 this model was improved upon by using pads over the countersunk tone holes and the metal ligature was invented. In the mid 1800’s the final major modification was made by Hyacinthe Eleanore Klose’ who used ring keys like those that Boehm had used for flutes in order to make the fingering system more simple.
Bass Clarinets
The first bass clarinets in the clarinet family were developed in 1772 by Giles Lot in Paris. They were called basse-tubes. They are in the keys of Bb, C, and A, have an Eb key, and are an octave below the clarinet with the ability to span 3-1/2 octaves. Between 1772 and 1836 different musicians in various countries constructed bass clarinets, including Adolphe Sax in 1836. The bass clarinet is similar in appearance to the saxophone in that it has a curved bell and the mouthpiece is attached to a curved neck. Their tone is full and deep and are more popular in free jazz or avant garde versus jazz.
Alto Clarinet
Within the clarinet family the alto clarinet in the key of G existed in 1792 and was later changed to the key of F and Eb. It never acquired a role in the orchestra, but was used as a tenor clarinet in British military bands since the saxophone was not in existence yet. Its best quality was its ability to project sound extremely well.
Contrabass Clarinets
Another member of the clarinet family was the Bb contrabass clarinets which were in existence since the 1800’s. They are an octave below the bass clarinet, have a rich tone, and are easily blown. Leblanc of France made a collapsible model with a mechanism which straddled the double tube. It was used in the London Symphony Orchestra.
Double Bass Clarinets
Playing at two octaves beneath the clarinet, double bass clarinets have a tone that is solid and full. Beginning in 1808, different versions were developed, but it was not until 1890 that finally an excellent one was made by Fontaine-Besson of Paris. The downside of this music instrument is that it was very expensive, so it was not used much.
Cousins To The Clarinet Family
Basset Horns
Basset horns were first made in 1770. They were made out of wood which was split lengthwise, then the two halves were hollowed out, and then glued together to form a crescent shape. This was then covered with leather. In 1800 the horn shape was changed to being sharply bent to an almost right angle. It underwent another shape alteration a few years later when Heinrich Gresner in Dresden tried to give it a straight form as it is today. Basset horns are basically an alto clarinet, but with a narrower bore, thinner walls, and four semitones below the low e.
Contrabasset Horns
Contrabasset horns were first developed in the beginning of the 1800’s by Georg Streitwolf in Gottingen. They are in the key of F and one octave below the basset horn. From the 1880’s into the 1900’s some musicians tried to revise them, but they were not used much and are rare.
Even though the clarinet has been quite popular, especially during the early jazz years, not everyone knows that it has taken quite a long time for the clarinet family to evolve since its early beginnings as a shawm in the 1400’s. It has many family members that are unique in their own way, yet very similar to the clarinet, just like any human family members. The sound of clarinets has also developed from a shrill, unpleasant sound to a tone that that is pleasant and captures a full range of emotions of the human spirit. If you would like to pursue your musical interests, you can find professionally crafted clarinets for a very reasonable price at http://www.djmusicstore.co.
Top 10 Advantages Of Favoring Swift For iOS Development
The significant launch does not imply the death of Objective-C, while it will become the de-facto language for iOS app development for iPhone, iPad, Mac, Apple watch and more devices.
The language which was illustrated as Objective-C without C by the apple, is safe, modern, faster, compiler optimized and packed with a high level of interactivity enables responsive and consumer-facing application development a breeze.
However, the release introduced a dilemma of making a decision between the two OOP languages-Swift and Objective-C. It brought a lot of confusion to the development shops and created a room for the discussions.
On a concluding note, the Swift was declared as a winner in the years to come and when leveraged for iOS application development, it will bring lots of benefits to the top of the table.
Take a quick look at how the Swift can get you ahead of the game:
1) Less coding required
In Objective-C, the string manipulation, string concatenation or class division needs more coding and involves writing repetitive statements. In Swift, the length of coding is reduced to half with the addition of new operators.
Also, the need to memorize the token gets alleviated with string interpolation where variables can be directly inserted inline to the string. The likelihood of app crashes due to order mess up is reduced with type inferencing system.
2) Dynamic library support
The dynamic libraries support to Swift began after the release of iOS 8. Before this, just static libraries were there, although Mac is enjoying the dynamic library support from a long time.
Dynamic libraries are the executable code that allows the latest Swift apps to link the changes or updates that new versions of Swift language bring over the time in an automated fashion. Dynamic libraries are included within the app bundle during download, but they are external to the app executable, which mitigates the app size because the external code is linked only when the language evolve.
3) Easy to read
With clean syntax, Swift has become easier to read and write the code and look a lot like plain English. The removal of all the legacy conventions like parenthesis for conditional statements, @ symbol, semicolons to end lines, nesting of method calls inside square braces and pretty more has made the language expressive and the code cleaner.
In Swift, the comma separated list of parameters within parathesis is used for function and method calls to simplify the syntax, due to which the Java, C #, C ++ or Python programmers can easily read and adopt the Swift.
4) Maintainability
For executable app creation, maintaining two code files is mandatory in the Objective-C to enhance the build time and efficiency. But, the legacy of two code file requirement was dropped by Swift with X-code and LLVM compiler.
The two compliers find out the dependencies, perform incremental builds and combine the implementation files (.m) and Objective-C header (.h) in one code file (.Swift) automatically. This way Swift minimizes the repetitive tasks, bookkeeping and workload thus the programmers will get more time to focus on logic creation, and code quality improvement.
5) Faster and safer
In Objective-C, the null pointers reduce the app crash probability but introduces lots of bugs that eats away a good amount of time of the programmers to find and fix them.
On the other hand, in Swift language, the optional value is very clear as compiler error is generated for the bad code, which enables the programmer to fix the code quickly that saves the time and money. Also, during the run time crash, Swift triggers by stopping at the line of code where nil optional variable is used so that the error can be fixed off the bat.
6) Unified with memory management
In Objective-C, the Automatic Reference Counting is supported within object oriented code and Cocoa APIs, but not available for core graphics and procedural code, which in turn make the programmers responsible for memory management.
Instead, in Swift, all the memory management at the compile time is handled by the ARC as it works across both object oriented code and procedural code, and won't require programmers to do any context switches. Additionally, the need to run garbage collector to clean up the unused memory is not required.
7) No more name collisions
The unavailability of namespaces support leads to code file names collisions, which is a linker error and won't let the app to run. In Swift, the implicit namespaces based on the target where code file resides are given, that's why the same code file for multiple projects can exist without letting the build to fail.
With name-space identifiers, the classes or values can be easily differentiated and the open source libraries, frameworks or projects can be implemented on-the-fly, which relieve the stress of the same code file name collision during open source project integration.
8) Performance
Under the hood, the changes are constantly made in Swift to improve the speed at which the app logic is run. The improved performance of GEMM algorithm by a factor of 1.4 and FFT algorithm by a factor of 8.5 are the great instances of it. The speed up development helps in saving huge bucks.
9) Playgrounds
With playground feature, the programmers get the space for experiments by writing a code or creating an algorithm and view its results on hand without having to wait uptil the project to completely built or emulator to test it.
It's more like editor window where the code gets compiled and run as soon as it's written, which aids in data visualizations. All the changes made during processing, from simple images to graphs to the finite control elements can be viewed in the real-time.
10) Open source
A year later after the release, the modern programming language Swift was declared as open source. The announcement made the language more popular, and highly used across various platforms or as a back end infrastructure.
Besides, the feedback from the community and developers' support has made the invaluable contribution to the improvements in the language.
Conclusion
In 2015, in the "Most loved programming language" nomination, Swift language top the stack due to the myriad of benefits it offers over Objective-C. The language was released by the Apple keeping the future iOS application development in mind. The host of features has made the iOS app developers to implement the Swift code during app development.
What are your thoughts? Do you also find the language equally significant for iOS development? If so, don't hold fire and set off the next project leveraging Swift.
The Global Economy As a Craps Game
Investment Banking and global finance is a lot like a big craps game. Maybe with one fundamental change though. Just assume that every payoff in craps is increased by 1 / 36th. What this means is that the advantage goes to the player. The players are bankers and hedge funds with capital to deploy. The advantage, which I'm suggesting can be expressed as an increase in the payouts for the various bets. I chose the unit of measure: 6 x 6, since all of the bets in craps pay out in various multiples of six.
Call it growth-rate. 1/36 is a little over 2%, and is the basic unit of advantage in craps. There's a premium in our world for doing stuff, so it's not a zero-sum game – and certainly not usually in favor of the house. Who is the House? Well, in this example it would be waste and failed investments. Non producing assets if you will. Think of it like this: There is a huge amount of capital to be deployed at any moment. It can be kept on the sidelines but someone is quietly stealing your chips if you leave it on the rack. We have to lay out the bets. Most are conservative, or at least hedged in some way. A small amount may be place on hard-ways, the field, horn, craps, etc. A lot of ways to lose and make money. Most of us don't do this every day, but the finance guys do.
It's probably enough just to say that they know what they're doing when betting on the pass-line (long, equity investment), don't-pass (short), hi-low (IPO), place (bonds, CDO / MBS, preferred stock,) and crap-check (credit-default swap).
The idea is risk management. Large amounts are laid out on the table at one time and the rolls are cast. Notice how every night the evening news reports the economy is either on a rebound or plunging into the depths of hell? There is a certain volatility inherent in the economy, certainly exacerbated by the efficiencies of information flow to automated systems. Even if we did not have the wonders of automated trading it still wouldn't change the fact that our entire system is built around our expectations of the future. Expectations that feed on new information. Volatility is like laying larger bets down at one time. I know that doesn't make a lot of sense, but it's supported by the math.
Bankers may have a little longer view than most people on some things. For example, we have 30 year bonds. We cash-flow on a pro-forma basis many years into the future. Our holy discounted cash flow model has all the answers, whose sum (turned into the Present Value of course,) equals our current expected value of, basically, anything. Bankers leave their place bets up and never take their hard ways down. Bankers will acknowledge the 5% disadvantage on the field, but time their bets as to when 4 non-field bets have come up in a row.
My comparison works even better if you realize that at various points in the past, the payouts have been even better. There have been several times in the last fifteen years that the payouts on various bets have been even better. The dot.com era was heavily favored on the horn and hard ways. Maybe up to 100: 1 on things like Apple, Amazon, and Google at various times.
The current economy has not only removed the basic 1/36 advantage, in fact it has taken an additional 1/36, maybe more. Money can still be made in the game – and the Fed (the house marker) will loan the best collateralized as much as they need. It's just that their daily play (many times per day for many market participants,) is now seen with a slight disadvantage. There are still plays to be made, but credit risk managers are playing conservatively. Not a lot of horn or hard-ways right now. The point is ten, and we're loaded on the pass line with full odds. Just hunkering down and hoping we don't crap out.
One of the problems inherent to the industry is that these players can't leave the table. Their job is to entice capital with the promise of returns. When the advantage turns back to the players (as it does under lower capital gains and corporate tax rates,) we will see a return to more aggressive game play. Is it? was that at ten? Shooter !!
Role of Python in Image Applications
In this article we are going to know how Python plays an important role in image applications. Python is a high level programming language that lets you work more quickly and integrate your systems more effectively. 90% of people prefer Python over other technology because of its simplicity, reliability and easy interfacing. It is often compared to Lisp, Tcl, Perl, Ruby, C#, Visual Basic, Visual Fox Pro, Scheme or Java. It can be easily interfaced with C/ObjC/Java/Fortran. It runs on all major operating systems such as Windows, Linux/Unix, OS/2, Mac, Amiga, etc. Day by day we can see a rapid growth in Python Development.
Python supports multiple programming paradigms and modules. Python is also supported for the Internet Communications Engine (ICE) and many other integration technologies. It is packed with rich libraries and many add-on packages to tackle specific tasks. Python is friendly language you can learn it easily. Python used in many business, government, non-profit organizations, Google search engine, YouTube, NASA, the New York Stock Exchange, etc. Python is often used as a scripting language, but is also used in a wide range of non-scripting contexts. It provides very clear and readable syntax. You can easily write programs using this language. The Python code runs more than fast enough for most applications. It is used in a wide variety of application domains. Python is an excellent language for learning object orientation.
Applications written in Python are
- Web Applications (Django, Pylons)
- Games (Eve Online – MMORPG).
- 3D CAD/CAM.
- Image Applications.
- Science and Education Applications.
- Software Development (Trac for Project Management).
- Object Databases (ZODB / Durus).
- Network Programming (Bittorent).
- Mobile applications.
- Audio/Video Applications.
- Office Applications.
- Console Applications.
- Enterprise Applications.
- File Formats.
- Internet Applications.
- Python in Image Applications
Always images play a big role in reaching the audience than the words in the web application field. Because a picture is worth a thousand words. Generally some users can satisfy with the existing images but some users want to make some creativity or changes to an image. In order to fulfil their demands Python provides various programs. Let’s see how Python used in imaging applications
- Gnofract 4D is a flexible fractal generation program, allows user to create beautiful images called fractals. Based on mathematical principles, the computer created the images automatically, include the Mandelbrot and Julia sets and many more. It doesn’t mean that you need to do math for creating the images. Instead you can use your mouse to create more images as per your wish. Basically it runs on Unix-based systems such as Linux and FreeBSD and can also be run on Mac OS X. It is very easy to use, very fast, and flexible with an unlimited number of fractal functions and vast amount of options. It is a widely used open source program.
- Gogh is a PyGTK-based painting program or image editor with support for pressure-sensitive tablets/devices.
- ImgSeek is a photo collection manager and viewer with content-based search. It has many features. If you want to find a particular item, you simply sketch the image or you can use another image in your collection. It provides you with what you exactly need.
- VPython is the Python programming language plus a 3D graphics module called “visual”. By using it you can easily create objects in 3D space and animations etc. It helps you to display the objects in a window. VPython allows the programmers to focus more on the computational aspect of their programs.
- MayaVi is a scientific visualization program based on the Visualization Toolkit (VTK), supports volume visualization of data via texture and ray cast mappers. It is easy to use. It can be imported as a Python module from other Python programs and can also be scripted from the Python interpreter.
Finally, we conclude this article that the Python Applications used in different ways in the image application. Not only in this field, it also used in various types of applications.