I'm migrating to Bootstrap 5.0.2 and cleaning up the bundling for optimization. With deprecated support for various older browser versions and the fact that Modernizr.js hasn't been updated since 2017, is this line even still necessary?
#Scripts.RenderFormat("<script type=\"text/javascript\" src=\"{0}\" async></script>", "~/bundles/modernizr")
There is browsers that does not support all HTML5 and CSS3 features.
Also more than users, Older versions of a browser are still in use,
To display your website properly in users' old browsers, should of Modernizr.js use
This is more project-specific question.
Maybe it's not necessary at all, thus complete waste of time & efforts when you know who exactly is going to use your work (for example, a closed group of clients with modern hardware and operating systems).
Besides that, it is absolutely wise decision to use Modernizr.
Ask yourself:
do you / how do you know you can use some modern (or even not-so-modern) browser feature without leaving a share of your users with nothing
can you afford angry user because nothing happens when he clicks on "Start application" or shaming layout failure happens
Case: you are okay with testing and providing fallback but Modernizr seems to you like overkill. You want just "feature" in document.body simple test.
is it a good decision to reinvent a wheel of feature testing even if it seems to you that what you are up to is a simple true/false test. Remember, Modernizr often goes way beyond simple tests, because, well, that's precisely what it is made for.
Related
What is the most current way to build a firefox extension? I realize this question as been asked many times before, but the answers I found no longer seem up to date enough, especially since the add-on builder has been ditched.
So far I have spent a bit of time learning XUL, the add-on builder, and the SDK. There are many tutorials out there for all and I have found it very frustrating to spend some time with each before realizing it is outdated. Even the SDK tutorials are often flagged "In need of technical review" or are a couple of years old.
If the SDK is the best way to get started, are the official Mozilla tutorials the most up to date? Are there other good alternatives?
Depends on the type of add-on you want to create and how much effort you're willing to put in...
Simple add-ons, like add-ons creating some toolbar button and/or interacting with web pages or doing some XHR to display some info: The SDK is likely best suited for your needs.
Everything that could be a Greasemonkey user script: SDK and page-mod.
Add-ons that are aimed at modifying/augmenting/enhancing Firefox (UI) itself are very likely better off going the XUL (overlay) road.
Very complex add-ons, that will e.g. will use some own dialogs/windows are likely better off using XUL (overlays) as well. Also it is kinda possible to use "websites" / html instead of real windows and dialogs (but usually the results suck IMHO).
If you're really into pain, bootstrapped (plain restartless add-ons without the SDK) are always another option.
You should keep in mind that the supported API of the SDK is still pretty limited and hides tons of low-level stuff by design. Therefore, right now, lots of SDK add-ons will use the chrome module anyway, and leave the safe surroundings of the SDK doing so...
I personally do not like the SDK, because I find it to be too limiting, and once you stumble upon a bug in the SDK itself (or at least think you found one), actually reading the vast abstractions that is the SDK is rather painful.
But then again the learning curve for simple stuff is rather tiny, so for beginners trying to create simple add-ons, it is a good fit.
I have a large ruby on rails 2.3 which was now a disaster because of the slowness and many bugs. I'm the only programmer and every day I've done debugging and tearing my hair off because of this. The users are already using the product but so many bugs and data are scattered.
I was employed without prior knowledge of project development and management. Now I'm suffering of having more overtime and a crisis on my codes to be fixed.
And also I've created this app while learning rails so there are codes there that became stranger to me.
What should I do?
What are your suggestions?
What books do I need to read about more?
Please I need some help.
Thanks.
I would love to recommend you upgrade to Rails 3. Especially since there are many newer features and some things are simplified, and it would ease future maintainability.
However, unfortunately, I am hesitant to (or rather simply cannot) actually recommend that given that you already have much more on your hands.
In this case, the best thing you can do is to start writing tests. If there are so many bugs, I have to assume that either you have no tests or your have an incomplete test suite. Tests will help to give you confidence that you do not break anything when you try to fix something else.
The default rails test framework can be found at the Ruby on Rails Guides. Having said that, many people prefer the RSpec testing framework. There are indeed shortcomings of the default Rails testing framework (notably the fragility of fixtures - try get a factory gem, and other features such as mocks and expectations, and nested contexts).
You should read up on the testing frameworks, and maybe try it a bit. Pick one testing framework early on however, and start testing everything!
Perhaps when you become more confident in your test suite and have fixed the most important bugs, you should think more about a path to upgrading Rails - because all the gems will march on, and gradually drop support for Rails 2.3, which means you will be using increasingly old gems which may no be well supported anymore.
From what I understood, you are asking for project managment tips and tools how to get a rails project under control.
I believe first thing you need to is stabilize the project. To do this, you will need to minimize the bugs and chart the required work.
I see two complementary approaches for this:
use a task/bug tracking tool
start using cucumber for testing
Task/bug tracking
This is very important, because you will need some kind of list that itemizes all bugs.
Sometimes users discover a bug, and suddenly you have to drop everything, because at that moment, that single bug is the most important bug ever, and needs to be solved immediately.
However, if you would ask them outright if this means the bugs you are fixing are more or less important, the answer could be different.
So it is in your advantage if there is a clear way to let the user participate in that decision process. If there is a shared bug-list, users can also follow the current state (what you are working on), they can indicate/choose which bugs are more important for them.
Secondly: having a list of items(work/tasks/outstanding bugs/...) will also help you planning the work.
There are a lot of options to some kind of bug-tracking, but some easy/pragmatic/free suggestions are
checkout trello
use the issues from github
Tracking the bugs/tasks will give you the feeling you gain control of your project, and furthermore: it will make this also more visible to your client.
Cucumber
When fixing bugs there is always the danger to introduce new bugs, definitely in a project that is originally not your own.
In a project where there are next to no tests, I always propose to start with cucumber. Cucumber has a few advantages:
it tests your application/website from the outside in: no need to understand the code fully, you just need to know what the application should do. If I click this link, it should take me to that page.
it is really easy to write tests in cucumber, and you get test-coverage really quickly
as a bonus, your test-code is readable, which you could show your clients/users, and they would actually understand what is covered by the tests (and could correct/improve it).
Upgrading or not?
I personally believe your first step should be stabilizing the project and minimize/remove all bugs. Whilst upgrading to rails 3 would be a huge improvement, it is not a straightforward process. There are good guidelines, but if you do it now, you will have no idea if a bug was introduced during the upgrade, or existed before. First get your code quality in order, and then do the upgrade.
Hope this helps.
Actually the thing you are asking is completely depending on how much refactoring you need to clean up the whole project. If you have enough time in your hand to clean it up completely. I would suggest following steps:
Getting Ready
Get the visualization of the whole project. What is required and what is not required.
Define your resources and relation between them properly.
Use proper RESTful routing.
Decide the test tools and frameworks like cucumber, rspec, factory girl etc.
Plan of Action
Decide (if possible, as a team) that what are the minimum or necessary changes required.
Isolate all the components in different groups so that each group can be refactored individually. Smaller groups are preferred.
Decide test cases.
Break down tasks into as much as small size possible.
Make sure to keep your test coverage more than 90%.
This process will take around 4-5 months for a medium scale project for a team of 4 members.
Let us know if you have any specific confusion.
What to read: http://guides.rubyonrails.org/v2.3.11/ Start with chapters about debugging and performance testing.
Forget about upgrading to Rails 3 for now, at this moment it would only introduce many more bugs and probably lots of problems with legacy gems and plugins. And don't forget that you need ruby 1.9 in order to upgrade to rails 3 - yet another batch of problems.
Adding tests is a good idea, as ronalchn suggested. I'd recommend to start with unit tests. You might have to rewrite code a lot in order for it to be testable. (In other words, instead of trying tests to fit current legacy code, it's usually better to refactor the code to make it testable.)
Unfortunately there is no quick fix in your current solution. If you seriously consider an upgrade, it will take time to fill in the missing tests if you haven't been writing them, pick up the testing frameworks on top of Rails 3, and work out the necessary data migration once you are ready to flip the switch.
The other option is to continue with Rails 2.x, which isn't completely unfathomable although the support avenues will be much more limited. You still need to work in the tests as a first priority and understand the various nuances that are present in the existing application.
For your scenario (one-man racket with little to no prior experience), I feel that sticking with what you have and improving the testability up to the point where you would feel an upgrade is worthwhile, would be the prudent action. No matter which course of action you would take, be prepared to put in quite a bit of work in the short-to-middle term (but such is the case of accumulating technical debt).
Though I am a programmer, I have never written for any Apple device. As such, my iOS-specific knowledge and familiarity with their API is nearly non-existent so please bear with me.
I would like to create an action from the lock screen (swipe, double tap clock, whatever) that would unlock and immediately open the App Switcher (I am not interested in extensions ala SwitcherPlus or the like). I guess this means writing a small script, and I could use some help concerning the API and other basics (the core features, shouldn't need any fringe stuff). While I am willing to get into the nitty gritty if need be, I am open to other solutions. Even something as high-level as chaining several Activator responses together would be fine.
I see Ruby under Cydia/Scripting (Telesphoreo). Though I'd slightly prefer Python or even Bash, being that my purposes are fairly minor Ruby would be just fine. I would rather not use Objective-C. While my original goal is the behavior described above, I can see myself wanting to do similar things in the future so some tips towards general know-how would be much appreciated.
If it is not clear, this a purely personal project. I am not at all concerned with packaging, sharing, backwards compatibility, commercial appeal, etc
PS - I have, until this point, set my Cydia viewing to "hacker" but not "dev". Does this endeavor indicate that I should up it to dev? The term seems a little generous, but if it opens up packages that I will need...
EDIT: I use an iPhone 4S, iOS 5.0.1
I don't think that this is possible in any scripting language. For one reason: You'll need to do code injection to achieve these goals (MobileSubstrate).
1) If you want to detect user interaction, you'll have to add ways to detect it or hook implementations which are already there. Even if you just wanna use Activator, you'll still have to develop a binary to register itself with Activator -> objC
2) There is no known way (at least to me) to interact with SpringBoard via scripts the way you want. So you'll have to make a binary which would execute the opening of the switcher.
I hope someone will have a better answer for you, but I'm very very sure that you won't get around using C/objC
There is a tool called http://www.cycript.org/ which is a bridge between JavaScript and objC, but I have never seen it being used for more than investigating.
This question contains a lot of background information, to make sure you fully understand why we are looking at these technologies.
The question is basically this:
For a large, spreadsheet-type, module that we need to develop for our webmodule for our application, are there any pitfalls we should know about if we decide to use Silverlight for it?
Issues we already know, and don't need any discussion/reminders about:
We're aware of the problems around using a plugin-type solution, which may or may not be installed on the users machine (and in some cases, probably can't be installed). These risks needs to be mitigated, but we're aware of them. Please don't get hung up on this.
We're a .NET company, so while ruby on rails and lots of other different platforms and architectures are good for this solution, they are not in the scope of the decision here. We have lots of code already written in .NET that we need to take advantage of, otherwise the project will never be finished regardless of platform.
Background
We have a web module for our application with employee-related information and some input forms. Our Windows desktop application is mostly a department leader type of application, to manage employees, but the web module contains mostly employee-centric functions. The web module contains mostly report-type webpages, to list information from the system, or input-forms.
The module we need to add now is more of a heavy spreadsheet type application. You change something one place, and something changes somewhere else, like sums, what is enabled/disabled, etc.
We know we can manage all of that with AJAX, but another issue here is that the application will potentially load a lot of database data in order to put the data in front of the user, and with a AJAXy solution, we're afraid that the request/response method here will have to reload quite a lot of information on every request, even to respond to seemingly easy questions.
A way to mitigate that would basically be to load information into a Session-object or similar, but that's a big no-no, so we'd rather not do that. This is a multi-user module, and some of the data is rather static, but some of the data is also going to have to be refreshed from time to time, so if 10 users loads a lot of data into the session, that's going to be a pretty big memory-hit.
We will be using ASP.NET (MVC) for this if we choose to go this route, that is, developing the module in pure HTML and similar technologies.
Then we looked at Silverlight, and would then load all the information down into the Silverlight application on the client. It would hold the current state, and would only need to touch the database to refresh some of the information, some of the time, instead, as we think the request/response model with ASP.NET (MVC) would work, on every little request.
But, since we have only done minor things with Silverlight, we're not that experienced with it, and we're afraid that some assumptions we might have, stated or unconcious, turns out to be wrong or flawed, which will make this project impossible or very hard to manage at some point.
For instance, just to take an example, is there a limit to how much memory the Silverlight application is allowed to load (I know, if I have to ask I can probably not afford it), for instance if there is a limit on 10MB, then that would be nice to know about before we're midway and start to load the really heavy data.
To make it simpler to give examples, let's just assume we're building a spreadsheet, that has so much data, that for the simple "changed a number here, what else changed", too much data from the database has to be loaded for a proper request/response model to be used, and if we move the entire thing to Silverlight, what will make that project hard or impossible?
Knowing about such things would at least give us the ability to consider if the price is acceptable.
In short, why should we not use Silverlight for this and instead go for ASP.NET (MVC)?
And again, "use Ruby on Rails instead", is not really an answer here. The options are ASP.NET (MVC) which we have experience with, or Silverlight which we don't but can gain.
Of course, if Ruby on rails, given that we'd have to start pretty much from scratch infrastructure-wise, and have to learn a new programming language, and framework, and download and learn a new IDE/tool, if it would still allow us to cut the development time in half, then please give us some information about how that might work, but I daresay that won't really happen here.
You should know that Silverlight (version 3.0) does not support any printing whatsoever, which to me sounds like a whopper of a showstopper for you (sorry, I couldn't resist). The good news is that full printing support has been added in version 4, but that is still in beta. Rumours say it should be out before the summer if everything works out according to plan, so if that fits with your roadmap I would use SL4 right from the start.
There are no memory limitations in Silverlight, but for the local storage (IsolatedStorage) mechanism there is a default limit of 1MB. But you can easily get around that by asking the users permission to increase the local storage space when he/she starts up the application. More on that here: Silverlight Tip of the Day #20 – How to Increase your Isolated Storage Quota.
(Edit)
Aside from the missing printing functionality that will be fixed in SL4 I cannot see any problems with your scenario. I would easily take the Silverlight route if I were you, especially since you already have extensive knowledge of .NET/C#.
For a rich interface as you've described, I would definately go with Silverlight or Flash rather than a html/javascript/ajax solution.
These technologies make for much better and consistent interfaces across platforms, you can buy in various components to speed things up and support things like copy-n-paste and code in a more structured way.
Another element is skills, if you have the skills to achieve it in a particular technology, then go with that.
To the answer you question the best way I can; you should not use silverlight if you decide to use flash.
HTH
My experiences with web-frameworks was that they are relative "unstable". Not that they crash but that there are quite a few changes which then force one to reprogram ones code. I wonder what web development packages you've used and how much work it was/is to maintain that code?
"Changes are a part of the requirement."
I dont think that the web packages that we design changes a lot. If it changes, then it is a bad design. If we use external API's, a very few get deprecated, otherwise most of them are the same.
Some packages used as a JAVA/J2EE programmer:
- MVC
- Struts
- few AJAX frameworks
These are very basic one used. Most the other ones are self developed and once the design of the web package is done, we don't change the design.
Any library which is under active development would be unstable. Look at .NET for example, every month there's a new better way to do old stuff. On the other hand open source libraries tend more to throw old deprecated methods away because it makes code better and that's what makes them happy.
But I wouldn't recommend to use anything old and unsupported anyway, you'll be on your own although the environment would be completely stable.
The best way possible seems to be just freeze the version of library you start using and switch to new one only there's huge benefit in doing so. At least that's how everyone is doing that.
Frameworks like .NET and jQuery have been largely backward compatible and allows you to use new features slowly.
Mootools however... the API broke so many things from 1.11 to 1.2 to 1.3. Upgrading was not straightforward in that case.
As a rule, I try to wait for something to be out of beta before embracing it in production code. An endorsement can go a long way too - since Microsoft has called jQuery the winner of client-side frameworks its been easy to encourage others to pick it up too.
Most of my experience is with Ruby on Rails, so I'll share what I've seen with it over the last few years.
Rails updates at a pretty good clip, but you don't really need to update unless you need features or the rare security patch. As an example, I have a rails app running in our company right now that was coded about 2.5 years ago that only needed to have some work done to it once this year to upgrade it to a new version to be compatible with apache mod_rails, it was originally written against Rails 1.2 I believe. Of course, that was an intranet app which didn't have any security requirements. All in all, it's been pretty pain free. If I had kept using mongrel + mod_proxy it wouldn't have only needed to be updated once for a security patch.
Rails is pretty secure, vulnerabilities are fairly far between. There have been a few more Ruby vulnerabilities than Rails vulnerabilities if memory serves me right, but all in all it's pretty solid, and upgrading your ruby shouldn't break rails, especially if you use a distro that backports security fixes.