As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
When do you feel that it's appropriate/necessary to take deeper dives into the source code of open source tools to gain an understanding of the toolsets that you use? (nHibernate, StructureMap, Rhino Mocks, etc.)
When it doesn't work the way I expect or I need to implement something that isn't described very well in the documentation or with examples. Usually, it's a response to doing something that I think should work, but not understanding why it doesn't. FWIW, this also applies whenever I can access the source code, regardless of how "open" it is.
I would say there are two scenarios for that:
When the OpenSource product is part of your core business (your company depends on it).
When you want to start contributing to it.
I start diving into the source code anytime I need to know: what does this do? Or why does this not work how I think it should. This comes usually after reading documentation, googling, etc.
Also if it's a framework I've used for a while - it's in my best interest to know the source code a little bit as a reference point to know how it works.
If you want to know how any framework works, you always have to start with: "What would this IoC/ORM framework have to do in order to perform this function." I find thinking from the inside out helps sometimes with frameworks.
You may need to do this if the toolset you are using does not provide functionality that you need, or if there are bugs in your tools.
For example, recently I was using a JavaScript grid library that did not support sorting a column by certain date/time formats - so I had to go into their code and understand how it works so I could come up with a workaround. In the end I had to implement this myself, and contributed the code back to their project.
I think in general, if you are doing something that requires deep diving, then you are probably doing something you shouldn't be doing. When you need to know things at a level where you aren't doing standard things, you need to think really carefully about whether you are doing the right thing or not.
The exception to this is when you are building something where the library is in the realm of your company's core competency. If you are building an online build system, you probably want to know way too much about the underlying build systems (Maven or whatever), and you should probably deep dive on those until you know them well.
Related
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 9 years ago.
I'm a beginner with TDD; I've just read TDD by example and now I can't seem to stop writing code in a TDD fashion. I've noticed that a lot of the time I'm writing a test, see it fail, correct it, and refactor. And then after some tests I see that there was actually a better way to write the interface all-along which leads me to want to change some of the previous tests.
It obviously makes a lot of code I write a waste of time, so I'm wondering if it is a good practice to write all of the tests at once (or at least try to) in-order to save time? I'm asking because I know it's not the standard way, but is it wrong?
The real question is "Do you get more finished code done in a given length of time?" It doesn't matter how many times you write it and throw it away if you get more in the end.
As you use tests more, you will get better about figuring out whether a test is good or not. Ask yourself the question, "Does this test help the code somehow?" Does it document how to use the code? Does it check that the code didn't get modified incorrectly when refactoring? Does it test the code works right on the "happy path" and for the kinds of failures that are common?
I would write one test and then one bit of code. You have to decide how much is "one unit" of code but you'll get a feel for it as you do it.
Then I would either update the test to make it better and improve the code to meet those changes OR write another test and update the code to meet that tests requirments.
And just keep on going. One bit of test. One bit of code. It keeps you focused that way.
Don't forget YAGNI. (You ain't gonna need it.) This is the principle that says you write code only for what you need right NOW. Don't write any code for "just in case" or "it's needed later."
Later will come with its own requirements. You will still know how to code it, maybe better because you will have more experience. What you think you will need may (or may not) be what you actually need when you get there.
Writing code too early is a waste of time and effort.
"The management question, therefore, is not whether to build a pilot system and throw it away. You will do that. […] Hence plan to throw one away; you will, anyhow."
Fred Brooks, The Mythical Man-Month
You're not the only one to come up with better ways to do things after they're done. You should actually plan for it. :)
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I'm putting together a simulation environment catered towards multi-agent/swarm robotic simulation. The parts I'll be doing from scratch are the math library, physics engine, and AI engine. These will be implemented in F#/CUDA. I'm looking for advice on how to best implement everything else - i.e. all of the other parts of a game engine. After a bit of research in the beginning, it seemed like OGRE would be my best bet but I'm still unsure. Basically, I want to concentrate on the physics/ai stuff and have some game engine do everything else for me - rendering, scene graphs, etc.
Something I'm confused about is how my F#/CUDA back-end will interact with the rendering engine/game engine. It seems like the popular engines are set up so you could replace parts of the architecture with your own implementations fairly easily... Which one would be best for me to use?
Since I'm using CUDA and will be rendering results from the gpu, how will this affect implementation of a rendering engine like OGRE? I know I can't be stuck just having to use straight OpenGL...
Currently, I'm looking at Ogre, Panda3D, jMonkey, and Gazebo. On the surface, Gazebo seems like it could be exactly what I'm looking for.
I am also considering Python and Lua, though I'm leaning towards the latter.
I'd like for this "simulation environment" to be able to easily converted to (or just used as) a real game engine. I know all of the elements would pretty much be there already, I'm just stating that in case it helps with giving me advice.
Also, I would really like for this thing to be able to run on the CUDA-capable Tegra 4s that are supposed to come out this quarter (last I checked). This may or may not be something that can accurately be determined at this point, but you guys will know better than me... i.e. if I want the possibility of future tegra/android use, I should do everything in jMonkey? Would it matter?
...Overall I'm most interested in advice on what architecture configuration would work well with a F#/CUDA physics & ai engine
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
Which book is best to learn SSIS. Actually in my project we need to take onput from CVS file and after processing the data in SQL server 2008 we have export it back to excel file. ASP.NET is used as UI for this.
Thanks,
Nabin
I completely agree with Cade in terms of simply working with it. I found that trying to follow specific "tutorials" to try and learn the package didn't really help but having a number of useful resources definitely came in handy.
At work, we had this book kicking around but really it just went over the flow objects available without going into any real-world examples. Jamie Thomson's blogs (here and here) are both excellent online resources though and have been really helpful for me personally.
Try this book:
http://www.amazon.com/Professional-Microsoft-Integration-Services-Programmer/dp/0470247959
The best way to learn SSIS is just to do it. Probably best to start and then refer to the book. Because the tool is so GUI intensive, I tended to get more after reading the book later once I was already familiar with the environment somewhat.
Reading the material some times couldn't solve your real time migration by missing some perticular functionality related to your project. I worked on your scenario case of migrating database to SQL using intermediate CSV or text files.
http://msdn.microsoft.com/en-us/library/dd537533(SQL.100).aspx
we migrated nearly 1TB in 30 min using SSIS 2008.
this could help to get the information on specific properties of souce file according to our requirements.
thanks
prav
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 9 years ago.
I was looking around SO to find some exercises or interesting problems to do when learning a new language. Mostly of the time learning a language directly from reading the book does not work, even when a book tries to make an application from scratch to end.
Besides Code Kata, 15 Exercises to know... and Project Euler what are some other resources?
Also, what if the language in question is mainly used for web development..or that is the main intent of the developer for learning the language. In those cases, I doubt stuff in Project Euler will help. Are there sets of functionalities that should be implemented in a web app for a developer to feel confident about his skills in that language/framework?
The main and best resource is tasks that you care about! Come on, don't you have a backlog of "N cool things I wish I could be doing (to make my life -- or somebody else's -- better)"?! I've had dozens and dozens of things on such backlogs ever since... well, as far back as I can recall. So pick one, and do it with the new language (or framework, or whatever) -- the fact that you care about the result, rather than it being an artificial task set by somebody else!, makes all the difference!
When learning a new language I usually build something that I've previously built in another language.
Try to rewrite some simple tools you wrote in another language, if it is possible. In this case you'll know what do you need to do it and what is the difference between those languages.
FizzBuzz ( this is for the req. )
Create something that the language you are learning is good at. For instance, if you're working with Ruby on Rails, make a data driven web application. If you're working with Perl, write something that does advanced text parsing. Most languages were created to solve a certain set of problems. Focusing on those problems allows you to learn the differentiating features of the language you are studying.
There are many puzzles and challenges you can take part in, such as Facebook Career Puzzles. These puzzles are for people who want to work for facebook, but there is no reason you can't try them even if you aren't interested in a job. They start from very simple, to complex.
Programming Puzzles for Interviews (you could write programs to solve these)
Programming Puzzles hosted by companies like this one are also fun.
I would say create something useful to help yourself, or try tackling some puzzles. In addition to learning new ways to tackle problems, you'll learn the language better.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
I know of osTicket, are there any other more compelling help ticket systems?
My company wants to use one and I am researching them now.
I forgot to mention, I will need to install it on our servers...so SaaS (software as a service) doesn't work.
There is good information on Wikipedia at
Comparison of Issue Tracking Systems
Personally, I'm fond of Trac, which has the capability of integrating with subversion, so when you check in a file, if you say something like...
$ svn ci -m "automatically fix any broken dates in the input. fixes #87"
....then Trac will automatically add this comment and close bug #87 for you.
"Best" helpdesk system is very subjective, of course, but I recommend Request Tracker (aka RT).
It has a default workflow built in, but is easily configured for alternate workflows using the "Scrips" and templates. Very extensible if you want.
OTRS, Cerberus
I like eTicket Support, is very simple to use and install.
It absolutely depens on what your goals are. The Bugzilla and Trac systems mentioned are nice but geared towards bug tracking, which is just very different from a tool you'd want to use in a helpdesk-type setup where end users would raise incidents.
If the latter is what you are looking for I'd suggest you take a look at OTRS which is a very capable trouble ticketing system. It also has ITSM extensions, which makes it able to support ITIL processes if you need to.
I recommend OTRS, its very easily customizable, and we also use it for hundreds of employees (University).
Howabout Bugzilla. Open source and what Mozilla uses.
Here are a couple that look pretty decent:
http://sourceforge.net/projects/smallhd/
http://sourceforge.net/projects/helpdeskcsharp/
TRAC. Open source, Python-based