Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
I am planning to develop a cross platform standalone app to support windows and Linux. TideSDK is my personal choice to go with. But, I have been actively following tideSDK(tidekit) for last 6 months and does not see anything about their product launch.
Can we expect tidekit to launch by near future?? or should we approach some other tool.
Just to be clear - you're not expecting to provide a version of the platform for us to use in 2014, but you're committing to releasing a plan in 2014 in which you will let us know when you plan to release the platform (which could be 2015, 2016, 2017, ...)?
Just trying to get my development options in place for 2015 and I'd like to know if you plan on having something available in 2015 that can be used for development, and if so, in which half of the year?
TideKit.com and TideKit have been discontinued. (This tidekit response mail)
TideKit was software for developing apps for all platforms simultaneously with a single base of code written in JavaScript.
The scope and complexity of the product made it difficult to assemble the platform all at once. This stemmed from a holistic approach to app development for all platforms. While creating a platform for JavaScript developers, much of the core engineering is in a variety of lower level languages that affect the speed of development. We considered delivering parts of our platform as we reached milestones, but this was not suitable for the start of trials.
We were widely criticized for not revealing our technical innovation in advance of our release. In a competitive environment, revealing advantages as you go can also mean assimilation as you go. We had already witnessed how quickly our technical advantages could be assimilated by competitors to our open source TideSDK product. Therefore, we held back with a view of delaying the duplication of features by competitors, increasing our technical barriers and working to protect our IP and business case until we felt we were ready.
In a startup, we talk about a Minimum Viable Product (MVP). In our case, our minimum viable product was much larger and more difficult to achieve. In total, approximately three years of research and development was committed with multiple developers working greater than full time hours. A factor that extended the development was an expansion of scope that aimed to lower friction in the app development process.
In Feb 2014, we created a system to queue developers with reservation system for the earliest possible access to TideKit. Our goal was to provide an early trial when it became available. Since the development itself was complex, we could not provide a date when ticket holders could start the trial process – but it would be following our betas, then moving forward as we scaled the platform.
We were clear with our language on the site concerning reservations. As a result, we expected little confusion about what was being purchased, our expectations of timing to market, or the terms of purchase for a reservation ticket. Purchasers were not paying for our product at this point, but for their position in a queue for a trial of our new technology. We also included a refund policy to ensure the terms of purchase for your ticket were available. The wait has been long, but not nearly as long as other difficult engineering challenges including Myo that pre-sold their product and were also delayed before successfully rolling out.
Throughout the development cycle we provided updates of our status via posts roadmap page, email to our ticket holders and communications on our social channels. We did our best as a team to open ourselves to questions and maintain a social presence.
At the end of May 2015, we communicated our strategy to execute a series of focused betas that would have seen the platform revealed publicly and incrementally. We were at a stage that parts of the platform needed developer feedback as we rolled these out consecutively.
In the days preparing for our first public beta, we recognized the extent to which our brand had been poisoned by our timing to market. A campaign of negativity that had begun several months earlier with followers and ticket holders had taken its toll on our team, brand, and business.
We believed the beta releases would soon bring an end to the negative talk. On July 8 and 9 we faced further eruptions on social media that reached the tipping point. With the discussion no longer about the product nor its future, this was far more serious.
We failed to bring the product quickly enough for you. As a result, we came to the serious decision to discontinue TideKit and dissolve our company.
We wish to thank everyone involved that worked on the product and with our team. This includes businesses, entrepreneurs and supporters of our vision for app development.
Your TideKit Team
Related
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 6 years ago.
Improve this question
I'm an ambitious millennial who has chosen to self-teach myself a few things that could obtain me success. One of them is software development - with two possible avenues for success - create my own website, and be my own boss. The other is - to get certified through Microsoft in my area of expertise and work for a company. My area of expertise? Well, I'll try to be quick here, I started learning ASP a long time ago, and then I learned ASP.NET WebForms, and then, most recently, I've learned and have gotten a pretty good grasp of ASP.NET MVC. So, my issue is this:
I've had my eye on doing this for a while now, and I noticed how Microsoft modifies its Exam's every year, so, every so often, I check on the MCSD testing page to see what's currently offered. At the time of this writing, what I'm interested in is becoming what's now, in December 2016, known as a Microsoft Certified Solutions Developer for Web Applications (the MCSD: Web Applications certification branch), but I just found out the certification expires on March, 31 2017.
The exact page that made me feel alarmed on the topic is - https://www.microsoft.com/en-ca/learning/mcsd-web-apps-certification.aspx - and, the exact quote was "Note This certification will retire on March 31, 2017. When the certification retires, all individuals whose transcripts list this certification as active on or after September 26, 2016, will retain the active status. Find out about the replacement certification, MCSD: App Builder."
As I said, I'm ambitious, and have a few avenues I can pursue. Although, as I said, I've been interested in getting this certification for some time now, but, it's just that I've been busy doing many things, and I'm unsure if I can complete the exam by that date, and the new replacement certification branch (MCSD: App Builder) doesn't make sense to me, I want to develop with C# and MVC, and I don't want to have anything to do with Azure - which is what that new replacement branch is focused on - while the current branch that's available till March, 31 2017 - has a specific exam for MVC developers (Developing ASP.NET MVC Web Applications). I don't understand why Microsoft feels this change is necessary, this is alienating developers like myself. I don't know what to do, I wish there was something I am unaware of here, and there still will be some kind of exam offered specifically for MVC (I mean, since MVC was introduced, there's been an exam specifically for it - and now, they want to get rid of the focus on it altogether when it comes to certification? Maybe it's because Microsoft just made ASP.NET and MVC (under the new "Core" Framework) to be open source...)
If anybody here has any reassuring information for me, or some kind of information that'd help in some way pertaining to this, I would really appreciate it.
I have both MSCD: Web Apps and MSCD: App Builder.
Web apps is based around the older .NET 4.5 and 4.6 framework of doing things, where as App Builder is geared towards the .NET Core and .NET Standard upcomings.
I believe you only need to do 2 exams for App Builder itself, but you need to hold a certification lower then it (which is 1 exam), instead of the 3 exams for the Web apps cert.
Basically they have just moved the structure around a little bit to better adapt to their newer technologies coming out and to make it a little easier for people to get certifications.
Technically the MCSD: Web applications certification is only valid for 2 years anyways once you've achieved it.
The current MSCD: Web apps exam has been around for about 3 years or so, expect that they will be making changes like this every 3-5 years.
I am interested in creating a desktop application using HTML5+webkit, and I'd like to be able to build a stand-alone executables for various target platforms like a .exe file for Windows and a .dmg image for Mac OS. I have played around with node-webkit, which seems nice except for the packaging / distribution portion. I also stumbled on TideSDK, but that project seems to be inactive. For example, the latest release I saw was a beta from November of 2012. Yet, it seems the core developers have switched to developing TideKit instead.
Does anyone here know if TideKit is intended as a replacement for TideSDK? Is TideSDK going away? etc.
Well, TIDE is now officially a dead project. I just got this email about 15 minutes ago.
TideKit.com and TideKit have been discontinued.
TideKit was software for developing apps for all platforms
simultaneously with a single base of code written in JavaScript.
The scope and complexity of the product made it difficult to
assemble the platform all at once. This stemmed from a holistic
approach to app development for all platforms. While creating a
platform for JavaScript developers, much of the core engineering is in
a variety of lower level languages that affect the speed of
development. We considered delivering parts of our platform as we
reached milestones, but this was not suitable for the start of trials.
We were widely criticized for not revealing our technical innovation
in advance of our release. In a competitive environment, revealing
advantages as you go can also mean assimilation as you go. We had
already witnessed how quickly our technical advantages could be
assimilated by competitors to our open source TideSDK product.
Therefore, we held back with a view of delaying the duplication of
features by competitors, increasing our technical barriers and working
to protect our IP and business case until we felt we were ready.
In a startup, we talk about a Minimum Viable Product (MVP). In our
case, our minimum viable product was much larger and more difficult to
achieve. In total, approximately three years of research and
development was committed with multiple developers working greater
than full time hours. A factor that extended the development was an
expansion of scope that aimed to lower friction in the app development
process.
In Feb 2014, we created a system to queue developers with
reservation system for the earliest possible access to TideKit. Our
goal was to provide an early trial when it became available. Since the
development itself was complex, we could not provide a date when
ticket holders could start the trial process – but it would be
following our betas, then moving forward as we scaled the platform.
We were clear with our language on the site concerning reservations.
As a result, we expected little confusion about what was being
purchased, our expectations of timing to market, or the terms of
purchase for a reservation ticket. Purchasers were not paying for our
product at this point, but for their position in a queue for a trial
of our new technology. We also included a refund policy to ensure the
terms of purchase for your ticket were available. The wait has been
long, but not nearly as long as other difficult engineering challenges
including Myo that pre-sold their product and were also delayed before
successfully rolling out.
Throughout the development cycle we provided updates of our status
via posts roadmap page, email to our ticket holders and communications
on our social channels. We did our best as a team to open ourselves to
questions and maintain a social presence.
At the end of May 2015, we communicated our strategy to execute a
series of focused betas that would have seen the platform revealed
publicly and incrementally. We were at a stage that parts of the
platform needed developer feedback as we rolled these out
consecutively.
In the days preparing for our first public beta, we recognized the
extent to which our brand had been poisoned by our timing to market. A
campaign of negativity that had begun several months earlier with
followers and ticket holders had taken its toll on our team, brand,
and business.
We believed the beta releases would soon bring an end to the
negative talk. On July 8 and 9 we faced further eruptions on social
media that reached the tipping point. With the discussion no longer
about the product nor its future, this was far more serious.
We failed to bring the product quickly enough for you. As a result,
we came to the serious decision to discontinue TideKit and dissolve
our company.
We wish to thank everyone involved that worked on the product and with
our team. This includes businesses, entrepreneurs and supporters of
our vision for app development.
Your TideKit Team
you are right, TideSDK is aging and pretty inactive today. And you're also right, we as a core team completely focus on TideKit now. TideKit is the future!
If you want to know the full story about why we stopped working on TideSDK and started TideKit, I recommend you to read our first Q&A. There you'll also find an answer about how we compete with node-webkit:
https://blog.tidekit.com/post/your-questions-our-answers-01
We've just reached the highest HTML5 score any app development platform ever achieved. If you want to know more about builds, like the ones you mentioned for Windows and OS X, you should read this
Desktop Builds
https://blog.tidekit.com/post/from-a-desktop-perspective-tidekit-for-tidesdk-developers
There is a new kid on the block for this sort of projects: atom-shell Based in nodejs and used to create the great Atom editor
Technical differences with node-webkit: https://github.com/atom/atom-shell/blob/master/docs/development/atom-shell-vs-node-webkit.md
Presentation at JSLA about "Native NodeJS Apps": http://vimeo.com/97881078
If you look at this blog post, they talk about how unsustainable the economical situation is
http://www.tidesdk.org/blog/2013/04/11/tidesdk-in-numbers/
and I can't find the tweet that was stating the reasons behind the transition from one project to another. But I guess that the blogpost speaks for itself.
Anyway, I'm delivering a project written in node-webkit ( because I starded on Tide but for the obvious reasons I had to switch ) and I'm using grunt for packaging and in the end is not that bad.
Electron (http://electron.atom.io/) is the new way to go.
I also had an app running on TideSDK (https://github.com/vinyll/worktimer.titanium) and I'll have to migrate it to Electron.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago.
Improve this question
I am making a Adobe Air software which needs to work on Windows, Mac and Linux. One of the issues that has confused me is the registration/licensing process.
Basically, I want users to try out the full version of software for a month and then buy if they find it useful. What I am not able to figure out is how the licensing would work on all these platforms.
There are no registries in Mac and Linux where I can store the trial information.
If I somehow maintain things locally in a db, post trial, if the user simply uninstalls and re-installs the software, the trial would start again for 30 days.
Don't want to store things in filesystem as that's not even close to actual authentication.
Doing an online activation of the software is a little resource consuming and has network dependency, so that option is also out of scope.
What way should I choose? what other options do I have? Does adobe provide any support for this... any 3rd party libraries that I can use for free?
I use LimeLM (https://wyday.com/limelm) to do licensing for my Adobe Air app (Windows and Mac, no linux). Like you I have a 30 day trial, LimeLM has a trial feature which is tied to the hardware, so uninstalling/reinstalling won't give users another free trial.
LimeLM requires network activation BUT you can allow for grace periods, so someone must connect to the network, say, once in 30 days of use to activate.
I agree with the above post that EncryptedLocalStore is a good idea as well.
Unfortunately the licensing options for Adobe AIR is limited. LimeLM is functional and cheap (they don't take a cut of purchase price). I looked at NitroLM, which is very expensive (I think they take 30% of purchase price) and very complicated - I could never make sense of it. Zaqon also is out there. I didn't like the way their licensing interface looked to our users. LimeLM was the most flexible.
Have you tried EncryptedLocalStore? Data stored in ELS remains even after app uninstallation.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
I have a client whose requirement is best met with an XQuery/XML solution. The problem I am facing is overcoming the risk associated with a lack of market place skills for these technologies.
This is maybe a sales question, but how have others overcome this objection?
I'll let someone else answer from a sales perspective or suggest technologies. Here's my project management perspective. I think you should do two things:
1.) Cost of ownership assessment
Draw out two or three architectures and try to amortize in hours, $$$, or some other quasi-imaginary metric the immediate and ongoing impact to the client. For each solution, how hard will it be to build? How many different engineers will you need? How many different skilled people will you need to keep familiar with the project to maintain it, etc. Does the benefit of not having to have separate middle tier and dedicated relational database people outweigh the market availability of XQuery people? You have identified that the problem is best met by XQuery/XML. Can you quantify this somehow to your client?
2.) Risk mitigation brainstorming
The idea here is to come up with a plan to reduce the possible impact to the client for the technology that you choose:
Start with a Proof of Technology project to gauge the difficulty and efficiency benefits for your staff / client to implement an XQuery solution
Develop an in-house expert / team:
XQuery Training is available
Share cost of supporting XQuery expertise with other projects and similar problem spaces at your organization / client
Expose the XQuery/XML portion of the solution through other means that don't require special skills
XML and/or JSON over REST
Some sort of data access object layer that doesn't remove the agile benefits of the XQuery technology
SOAP services (yuck)
Build a relationship with a service provider who knows their XQuery well
From more of a sales perspective it is important to realize that there is actually lots of XML expertise in the market. XQuery expertise, while perhaps more widely available than you might think, is more limited.
I would look to find an XQuery/XML technology that meets a couple of important criteria:
Numerous successful customers who are willing to act as references. Pointing to successful implementations in production and, even better, allowing your customer to talk with some of these implementors, can be very powerful in reducing the perception of risk.
Provides development tools that allow for rapid development and reduce the amount of initial XQuery knowledge provided. For example, look at this open source framework where you can access nearly all of the underlying XQuery functionality via REST services or even via language specific APIs built on top of REST: https://github.com/marklogic/Corona
Have a robust training program that is accessible and reasonably priced. The cost of training is often low and the risk reduction is high.
Have an active community of developers and open source projects. This will allow you to leverage a lot of existing work done by the community as well as general development knowledge resident in the community, further reducing risk.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 12 years ago.
Improve this question
Recently a friend of mine had gone from a high level NOC position to a developer. Before that he was just doing the help desk stuff. He has no degree, only the usual MIS/networking certifications and as far as I know only tinkers with code on the weekends. I can see where in some scenarios having a good understanding of configurations, packets, users, OU's, etc would be extremely beneficial to a developer.
My question is this, how many full time developers started off this way? Even how many people dual wield the responsibility of developer/systems administrator/network administration?
I'm sure that this is a fairly common scenario. I've spent 12 years in I.T. and I find that as time goes on, the real income comes from being a specialist (DBA, coder, etc.) as opposed to a generalist (network admin, helpdesk).
It's actually the path that my career is taking. I'm not quite a full-time DBA or developer but that's where I'm heading.
I'm also willing to bet that the people skills I've picked up along the way (helpdesk support, network admin, systems analyst) will help me in my DBA/Developer career. Skills I don't feel I would have gotten had I jumped right in to a coding career.
Indeed. I think developers should know the platform they are building software for. If a dev has worked as sysadmin before, he will know how to integreate his software well. Some Windows-Desktop-App related "integration smells" that come to my mind:
App does not run unter normal-user privileges (run on properly secured enterprise desktops? oops!)
App requires write permissions to all kind of system folders (security? oops!)
App stores user settings in 'nonstandard' locations like %programfiles% (backup? permissions? oops!)
App does not provide silent-installable setups (deployment? oops!)
Etc..
A real sysadmin would never write software that has one of the above integration smells. Really.
It's quite common in small companies. I did that for some time - developing the software we sold to customers, keeping the network going, and adding features to the database as needed for a manufacturing company of fewer than 20 people.
You wear many hats in a small business.
But I started off programming microcontrollers in high school, so I can't claim this is where I started.
It is very helpful to have a working knowledge of all these systems as a developer.
-Adam
The overlap of developers and admins happens quite a bit. Our last admin developed on the side just so he'd have a better understanding of what he was helping support. When he left I became the admin just because I tinkered with admin stuff on the side to know how my software was being supported.
A broad understanding with a few focuses is what I'd say is best for any technical professional. Then with a bit of study you can change to meet whatever need may arise.
I've seen it more the other way where a programmer also "admins" the servers and sometimes network. I've definitely been in that position.
I would think it can easily go the other way as well where an admin can start programming systems, but from my experience it's not as common. Whenever I ask a server admin or network person "do you program too?" most of the time the answer is "no".
I think it might be easier for programmers to cross the line because when you are programming a system unless you always have an admin available you need to be able to set up your own environment and that usually includes setting up a server.
I started off as a NOC operator, eventually working my way up to a senior network engineer position. During the last 2-3 years of my tenure at my previous company, I picked up a fondness for programming and started teaching myself everything I could on my own time. Around 2005, I left said company for a small startup and still work there today as as the admin and primary developer.
The one challenge I impose upon myself is to not make admin changes at the drop of a hat to satisfy programming challenges. I must force myself to code in a way that any application I make can be redeployed elsewhere with minimal privileges, despite the fact that I can do pretty much anything I want with our own servers. It's a fine line between performing both duties well and performing one duty badly due to the needs of the other.
I'm here.
Although I've been tinkering with code since I was a child, my first full-time job was being a system administrator, a DBA and other related roles.
Afterwards I worked full time job as a developer, and now I'm both a developer and a security researcher.
Also, I managed to complete M.Sc in CS.
I believe that such transitions are possible, and very beneficial, as you get a wider view on your field of work.