This may be a fools errand, asking this question, since it is such a broad subject. But I'm a little overwhelmed as a jr. Developer trying to figure out where to start.
So far in my few month long career, I've been working with smaller projects, small ui modifications to existing projects. Now I'm being tasked with merging, or making 3 different projects compatible with one another, much larger than anything I've even seen, let alone worked with.
The code is complex, and a lot of it is pretty advanced. This is looking like it might be a few month long ordeal. Is there any advice you all have as far as learning other code bases? Understanding their architecture/functionality?
Unfortunately my NDA precludes me from giving out any specifics about the project to perhaps get more information, and I'm the most senior person on this team. Any and all advice you can give me about where to start learning a large code base, with lots of functionality would be helpful.
This question is indeed too generic to be addressed here, maybe https://softwareengineering.stackexchange.com/ could clear some of your issues in tackling new projects or specific technologies.
If you have specific questions regarding issues you find with compatibility between the technologies you have to integrate then we might be able to help.
One generic piece of advice I would give anyone tackling a new task is to take your time to first understand the requirements and the projects you are going to work on.
Another piece of advice would be to ask for a more senior programmer help you with the task, even if he can not actually work on the project he could still guide some of your decisions. It's always good to have a someone to bounce your ideas on.
Also considering that you are the most senior in the team, remember to consult with your colleagues.
Every project is different though and there's no specific solution we could give you to help you complete such a generic task.
I started learning programming a few years ago with java (minecraft, anyone?) but I only got to the point of creating tic-tac-toe playable on the console and then stopped.
Now, with codecademy, I have finished the html, css and jQuery courses and now intend to delve into javascript. My plan is to make an app for facebook with a colleague, app which would alert everyone on the class the week before a test. To do this, I would need a working calendar that kept "scanning" the date and once he found that there's something to alert on a certain day, it does.
Is that possible to do with javascript?
Thanks, everyone!
In short, to answer your question, developing the app you've mentioned is not possible only by involving some html/css and javascript. See the more in depth comments posted in the thread I mentioned in my comment.
Possible, no.
I don't know if I understand your question, but I'll try to answer ;)
If you need calendar try this
You will need something like "Facebook api" to load dates from FB calendar
Why just don't try to
find some function like "notify me 1 week before event" --> possible
with Google calendar
I'm not very interested in JS, but I think that it's better to scan database, not a website. And what type of app do you want to create? Faceboom app or website?
I have a free web site that streams real-time stock-options data. I want to let users make and then save their own JavaScript-callable tools to interpret options data. Users can invoke these custom tools to help them make their own sell/buy decisions about options.
But I am totally stopped, stymied, dead-ended, and buffaloed as to how to accomplish this. If there were just a few choices, I guess I could stumble around blindfolded (as I am now) and finally hit on one that kind-of worked.
But the choices seem endless:
Let the user write JavaScript tools that I'd then interpret;
Mathematica and like toolsets;
Many statistics packages;
Google spreadsheet API.
And overwhelmingly many more.
If anyone has struggled through the process of giving a user some facility for making statistics and probability tools, how did you finally end up? And would you do it that way again?
Plus, my feature-creeposis and perfectionitis want me to integrate charts, graphs, heat maps, and who knows what else more; or at least to allow later integration of graphics.
Graphics would be nice and sexy: I'd like to drop everything and do graphics. But I have to resist and get something onto the page real soon now.1
Q: What can/should I do to allow and encourage easy, intuitive, secure, and powerful tool construction?
EDIT: I definitely don't mean that I want to invent a whole new system de novo. I only (uh-huh, yeah, that's right; 'only' :-) want to interface with some already-existing JavaScript-callable package.
Thanks so much!
1 Now I know a little bit of how my employers might have felt about me at one time: "aw, c'mahhhhhhhhhn, this feature is just too sexy to leave out."
If you need to get something out the door quickly, the first best stop-gap solution is to give people the ability to export their data to a tool they already know how to use (e.g., Excel) for exactly this purpose. Worry about your own version of the wheel once you've provided some basic short-term solution.
Of course, that's not to marginalize the topic of building a functional, browser-based statistical analysis package, which certainly seems interesting. But to be perfectly honest you might as well come to SO and post "Hey guys, I need to develop a new Operating System for the iPhone. Any ideas?"
;)
I am using jQuery Fullcalendar and if you're not using it I suggest you do too because it is absolutely fantastic at what it does!
However to be really useful to me and my project (and many others) I honestly believe it needs a resource/gannt view.
Not a problem one would think... until you look under the hood of jQuery FullCalendar and see that the way it generates it's views is not for javascript developer wannabes... ie me.
Having realised this is out of my league I had to go searching elsewhere looking for any calendar/scheduler that will provide a resource view.
Here are three proprietary calendars that promise this feature.
http://java.daypilot.org/
http://www.dhtmlx.com/docs/products/dhtmlxScheduler/index.shtml
http://web2cal.com/ajaxeventscalendar/calendar-demo/912-premium-demo/157-scheduler-view
Unfortunately both daypilot and dhtmlxscheduler lack the clean and clear interface that FullCalendar achieves so well and web2cal just looks and feels unfinished and is still in Beta.
Alternatively I was wondering if anyone has any ideas on how I could integrate a jQuery Gannt chart with jquery fullcalendar.
I have found a few projects that look promising
http://www.maro-z.com/examples/jquery.gantt/
http://code.google.com/p/jquery-gantt/
http://github.com/thegrubbsian/jquery.ganttView
I have looked into how fullcalendar generates its views and so far have not had any success in extending this to provide a container for one of these gannt charts to 'sit within' fullcalendar and be triggered by its buttons.
This seems to be one of the more popular feature requests with many people asking for it on the official issue tracker
http://code.google.com/p/fullcalendar/issues/detail?id=150&colspec=ID%20Type%20Status%20Milestone%20Summary%20Stars
So I am left at a cross roads. I could pay for a half baked proprietary solution that has minimal to no community support or I can try and find a way of getting a resource view inside of jquery Fullcalendar by asking the people who really know jQuery.
I would happily donate the funds saved from using a proprietary solution to the developer of Fullcalendar.
The developer of FullCalendar seems to have a lot on his plate and I would like to again thank him for this truly amazing calendar.
I hope someone can share a solution with us!
Tim
Just to update what has been done for this idea:
https://github.com/jarnokurlin/fullcalendar
It's now a fork of fullcalendar.
For those searching for a resource view based on v2.1.1.
Here is a fork implementing it that will hopefully be merged into fullcalendar at some point.
I know it's a pretty old question, but I was looking for something like that a few weeks ago and I couldn't find anything here. So, what I'm using is Kendo Scheduler. It has a horizontal grouping, vertical grouping, timeline and some other interesting things like bind against SignalR.
Moreover, FullCalendar announcement that it will be a Resource/Timeline view soon. But probably it will be released under a commercial license.
As far as what StackOverflow users can offer you as an answer, this is as close as you'll ever get:
http://code.google.com/p/fullcalendar/issues/detail?id=490
There is an open task and at the bottom are some work-in-progress examples of extensions to fullcalendar to achieve what you want. Please offer to contribute or clean up the code there to get it merged into the mainstream fullcalendar project.
There is a https://dhtmlx.com/docs/products/dhtmlxGantt/ which has a resource view as well. You can integrate it with full calendar. It's quite simple.
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 9 years ago.
Improve this question
I'm currently using the Yahoo YUI javascript library in a couple of my projects.
However, I'm a little concerned about three things. First, they laid off 10% of their employees. Second, their stock price keeps falling: especially after ignoring the MS takeover earlier this year. Third, what if someone does buy them?
The only reason I bring this up is that I tend to build applications that are going to be around for 8 to 10 years.
What would you do?
As a member of the YUI team, I would add the following to this conversation: Almost everyone who has ever worked on the team is still with Yahoo and still working on YUI -- a remarkable consistency for a project that is now almost four years old. No one can predict the future of Yahoo at this point (or of any other company), but you can bank on the code you're using today. It's free, open under BSD, and no one can prevent you from using it regardless of what may happen in the future.
We continue to be excited about YUI and we think its next four years will be better than the last four.
Regards,
Eric
Yahoo is a major company that won't end in the next couple of year.
The Yahoo! library is open source so you will have other people to continue to improve it IF Yahoo would go bankrupt.
No technology is 100% safe for 10 years perspective, I think you aren't in danger with it.
In 10 years Javascript will be completely difference and most framework will not be the same so I think whatever you choose you will need to change a lot of thing in 10 years ;) Just be sure to keep a version of the code in you repository to always have the latest version that work for your system and you will be fine.
Everyone else here has already mentioned that YUI is open source (and thus, can be extended, forked, etc)
But the important thing to note is that Yahoo USES YUI on their own web properties. It is a valuable project to them, not just as an internal component library, but as a standardized way to write JavaScript code. Once you wrap your head around that, you'll realize that if Yahoo is still on the internet, it'll probably still be putting resources into YUI.
Also, albeit a huge fan of jQuery, a levelheaded developer cannot seriously recommend a particular framework over another without having a project context and design considerations.
You can't just assume that your square peg is going to fit in everyone's round hole, no matter how hard you try to jam it in.
I switched to jQuery a while back and have been much happier since doing so. You should consider the fact that YUI is open source, so you could always make any needed updates you need in the future.
Switch to jQuery?
I learned YUI prior JQuery, and the problem with YUI is (in my opinion) is over engineered, meaning that is more complex. JQUery is fun to code and at the same time you can do everything with it.
My advice would be to use JQuery, and if you need some YUI component then use both. However i don't see any particular advantage of YUI over JQuery.
Even if Yahoo! goes under, their library is open source. The community will most likely pick it up and continue its development.
I've switched over Jquery recently, and the boost in productivity is noticiable.
YUI does have better docs, but it will break compatibility on 3.0.
Leave your legacy code on yui, and switch to jquery for new devs.
I don't think its ever safe to say "one library for all solutions".
Its always best practice to analyze each project you do and then decide which library to use. Whether that be jQuery, YUI, mootools,etc.
To answer your question a bit more bluntly - don't worry. The web is one of the fastest growing and evolving sectors out there. I would be surprised if your projects don't get re-developed (by you or someone else) in the next 3 - 4 years.
If your web app exists for more than 4 years in it's current form, then that's amazing. That will mean it's dealt with new browser technologies and possibly loss of existing ones. It also means that the site will not need major modifications in that time.
Most web applications I have worked on have been nearly completely rewritten after 3 years. Usually this is because requirements change; usually there are so many additions in that time that it's a completely different piece of software.
Also, in 8 years, I'm sure the YUI will have changed so much that it won't even be the same. 8 years ago it didn't exist; 8 years from now it maybe something completely different. This doesn't mean you can't continue to use the existing libraries exactly as they are.
The only thing you might think of doing is keeping versions yourself. I don't mean loading them from your own server, but just keeping them somewhere. Even just incase YUI changes something and ends up breaking something you were using--not likely.
I think any library is subject to these same concerns: YUI or jQuery, etc.
Well, Yahoo is still a profitable company with over $3 billion in the bank. I don't expect it to go bankrupt anytime soon unless they do something really awful.
However, Yahoo still needs to cut costs and they could just stop developing YUI to move the developers to other places. Just something to keep in mind on whether or not you choose to continue on w/ YUI. At it's current state, I don't see YUI being a revenue generator which is what Yahoo needs right now.
I've used YUI on a project 1 year ago.
I was pretty satisfied with the library even if I found really hard to grasp the way it worked.
After I while I discovered jQuery and tried it on another project.
Man, that was another world.
These days I am doing some changes to the old YUI project.
I wanted to port everything to the 2.8 (from 2.4.2).
I expected it to be easier but it wasn't.
After having spent few months on jQuery I must admit that YUI is overly complex.
You can do almost everything and configure every aspect of your App but, well, it takes ages to understand things, or at lease for me.
jQuery is much better and faster.
The plugin system is amazing.
I didn't try YUI 3 cause I've decided jQuery is good enough for me.
If the library does what you need it to do today, I see no reason not to use it. 8-10 years is a long time for a web-app but I'd like to think Javascript will still be around.
If you are using it with the expectation that it will have great advancements in the future then your concerns are valid but I think the same can be said for almost any technology/language/library. And since it's open source you or others could continue the development.
Here are your options:
1. Build your own Javascript library
2. Use the existing YUI library
3. Use some other 3rd party Javascript library
You can download the entire YUI library and run it from your own web server, so you don't need to depend on Yahoo servers. The code is open source, so you are free to make enhancements yourself if Yahoo stops building it. Given that, I personally think using YUI is much better than trying to roll your own Javascript library. I see a ton of benefits with virtually no risks.
The question that remains is whether you should use YUI or some other 3rd party library. Just about all the other open source libraries share the same future risk as YUI. I would personally look at the features each library supports and pick the one that currently supports everything you want (or the most of what you want).
First, It's open source so you can continue to use it no matter what happens to Yahoo. Besides, no one thinks they are going anywhere anytime soon.
Second, no matter what third party library or tool you use, you're always faced with the risk of them abandoning the product at some point, or even worse, the company going out of business.
Regardless of either, you can still use it after either of which happens. And not until then do you really need to switch? Also, the way the web has been changing, you may not want to use YUI in a few months either way, who knows?
jQuery is for coding, YUI is for learning.
jQuery is more widespread than YUI because it is easy to sprinkle it on web pages that need simple DOM manipulations and basic AJAX or animations.
YUI is an extremely popular library that has historically been a favorite of more advanced developers and application builders.
jQuery is too small and tiny, so that you have to find other frameworks/libraries to working together. You have to take a lot time of investigating test framework, ui framework. MVC frameworks...
But if you choose YUI, it's enough!!! test frameworks(browser and headless), ci tools, widgets, css grid/architecture, AOP, MVC... all the fancy features you want in one Framework! that's really kool.
So if you start a enterprise project, I suggest to use YUI, though it's learning curve to be a bit steep.