The Big Programming Thread - Page 406

Prev 1 404 405 406 407 408 1032 Next

Thread Rules
1. This is not a "do my homework for me" thread. If you have specific questions, ask, but don't post an assignment or homework problem and expect an exact solution.
2. No recruiting for your cockamamie projects (you won't replace facebook with 3 dudes you found on the internet and $20)
3. If you can't articulate why a language is bad, don't start slinging shit about it. Just remember that nothing is worse than making CSS IE6 compatible.
4. Use [code] tags to format code blocks.

sluggaslamoo

Australia4494 Posts

December 04 2013 22:45 GMT

#8101

On December 05 2013 00:30 darkness wrote:
Does anyone here like Objective-C? I'm starting to hate it with a passion by now. I find Java's syntax and way much better and easier.

It has some nice features, it was great for its time but I'm sure if it wasn't for apple it would be long dead by now.

bangsholt

Denmark138 Posts

December 06 2013 01:27 GMT

#8102

On December 05 2013 07:45 sluggaslamoo wrote:

Show nested quote +

It has some nice features, it was great for its time but I'm sure if it wasn't for apple it would be long dead by now.

Thanks for your opinion and all the great argumentation you have present on the subject of why you are starting to hate it with a passion.

I'm currently playing around with a great mix of Jenkins, Stash and JIRA, in order to make it build automagically and run a few simple static code analysis and unit testing on my code.

People out there who have actual experience with how well this works in a work scenario - I'm thinking it will work great, because it will enable us to put out a lot of metrics, which then can be measured and possibly drawn conclusions on, if someone feels that brave, but I would like to hear from people who have a similar setup as well.

Thanks in advance for your time.

WarSame

Canada1950 Posts

December 06 2013 02:22 GMT

#8103

One of my courses had a big semester long project creating an app(mostly focused on the documentation, we had to create it at the end). I spent probably 15 to 20 hours on my part(the entire front end and logic for it, etc.), and a lot of frustration, over 1.5 weeks or so before the deadline. Was polishing it up 2 days before it was due. One of the other guys spent even more time than me(doing the database, etc.) and finished around the same time as me.

The connection between our app and the server was left to a third guy in our group. We tried to talk to him over FB leading up to this due date for 1.5 weeks and hardly got any replies. With 2 days to go we organized a meeting at 10:30. He showed up at 1:30. He had a bit of connection working("Don't worry guys, once I get this it's smooth sailing!"). The day before we had a meeting at 10:30 again. He showed up at 2:30 because he slept in. Still had a bit of connection working. Same line. The Database guy spent the rest of the day trying to get his own version of the connection working. I stayed with them to help out. Left at 1130, got back at 1200, had to spend 1.5 hours documenting my stuff. Went to sleep at 130. Woke up at 7 to head to school to present. Guy who was supposed to do the connection was there, still trying to get it to connect. We head into the meeting. Guy starts copying down another group member's logbook(which says who was at meetings, etc.) that says he hasn't been at any meetings IN THE FUCKING PRESENTATION. He's also coding, trying to get the connection to work, still feeding us the same line. I present the front-end, DB guy present DB. Connection guy shows the non-functional code. We leave.

I get home, try to make it work for my own curiosity. Find a guide online, copy/paste the code. 25 minutes and I have a fully working asynchronous connection.

Fuck group projects.

/vent over. Steam has been released.

icystorage

Jollibee19350 Posts

December 06 2013 02:41 GMT

#8104

Can you guys suggest on how to practice TDD? I know how it works but I want to get into the 'habit' of it. It just feels awkward writing tests first.

sluggaslamoo

Australia4494 Posts

December 06 2013 03:10 GMT

#8105

On December 06 2013 10:27 bangsholt wrote:

Show nested quote +

What is it you want to know? Continuous Integration and Testing is one of the reasons I actually get hired haha

I mean yeah I've used Jenkins a lot, JIRA I don't really like but then again I don't really like any kind of digital scrum/agile software and prefer to use real cards, I don't have experience with Stash specifically but Atlassian software seems to be very good in general from using Bamboo.

It will be a long time before I move away from Github though if ever

sluggaslamoo

Australia4494 Posts

December 06 2013 03:13 GMT

#8106

On December 06 2013 11:41 icystorage wrote:
Can you guys suggest on how to practice TDD? I know how it works but I want to get into the 'habit' of it. It just feels awkward writing tests first.

Yep, even people who have been doing TDD for a long time still pretty much don't know what they are doing.

Knowledge is far more important than practice in this regard, you need to hit the books and find out as much as you can. There is a lot to know, its taken me several years before I feel like I can test as fluently as I can implement and I know exactly what I'm doing.

I don't really have the time to answer such a general question here, so if you have a more specific question or an example I am happy to answer that for you.

tofucake

Hyrule19167 Posts

December 06 2013 03:48 GMT

#8107

On December 06 2013 11:22 WarSame wrote:
One of my courses had a big semester long project creating an app(mostly focused on the documentation, we had to create it at the end). I spent probably 15 to 20 hours on my part(the entire front end and logic for it, etc.), and a lot of frustration, over 1.5 weeks or so before the deadline. Was polishing it up 2 days before it was due. One of the other guys spent even more time than me(doing the database, etc.) and finished around the same time as me.

The connection between our app and the server was left to a third guy in our group. We tried to talk to him over FB leading up to this due date for 1.5 weeks and hardly got any replies. With 2 days to go we organized a meeting at 10:30. He showed up at 1:30. He had a bit of connection working("Don't worry guys, once I get this it's smooth sailing!"). The day before we had a meeting at 10:30 again. He showed up at 2:30 because he slept in. Still had a bit of connection working. Same line. The Database guy spent the rest of the day trying to get his own version of the connection working. I stayed with them to help out. Left at 1130, got back at 1200, had to spend 1.5 hours documenting my stuff. Went to sleep at 130. Woke up at 7 to head to school to present. Guy who was supposed to do the connection was there, still trying to get it to connect. We head into the meeting. Guy starts copying down another group member's logbook(which says who was at meetings, etc.) that says he hasn't been at any meetings IN THE FUCKING PRESENTATION. He's also coding, trying to get the connection to work, still feeding us the same line. I present the front-end, DB guy present DB. Connection guy shows the non-functional code. We leave.

I get home, try to make it work for my own curiosity. Find a guide online, copy/paste the code. 25 minutes and I have a fully working asynchronous connection.

Fuck group projects.

/vent over. Steam has been released.

Blisse

Canada3710 Posts

December 06 2013 04:20 GMT

#8108

First week thrown on iOS project. iOS development is pretty fun.

Die4Ever

United States17718 Posts

December 06 2013 09:10 GMT

#8109

reminder I have source code for the WCS Predictor 2014 online http://www.teamliquid.net/forum/viewmessage.php?topic_id=436957

don't let some graphics guy beat out the programmer who made the Blizzcon Predictor and is working on the WCS Predictor 2014

please vote for me, Die4Ever, in Group P
http://www.teamliquid.net/forum/viewmessage.php?topic_id=436997

njt7

Sweden769 Posts

December 06 2013 11:53 GMT

#8110

Yeah I hated objective-c when I first started out with it, I came from c++/c# so it was almost all similar except weird. But after a while it doesnt really matter and further down the road it was very enjoyable to work with. I especially liked to work in Xcode when I learned the platform. Everything new can be frustrating in the beginning, just take some time to learn your environment and all the smart stuff it has to offer you. Dont dwell on what you dont have and rejoice over what you get etc.

bangsholt

Denmark138 Posts

December 06 2013 13:05 GMT

#8111

On December 06 2013 12:10 sluggaslamoo wrote:

Show nested quote +

I've read the idea with CI is that you make a new build every time you commit to the Git server on the master branch. What I don't really understand is the part where testing comes into the picture, one would assume you run all the tests prior to commit the code, and each commit should be atomic.

Or is it a case of you over time accumulate some tests that take a lot of time to run and you don't want to run each time that you compile?

It's this sort of questions I wonder a bit about - again, thanks for your time

Deleted User 101379

4849 Posts

December 06 2013 16:55 GMT

#8112

On December 06 2013 22:05 bangsholt wrote:

Show nested quote +

There are different kind of tests:

On one hand there are unit tests, which are meant to be fast and small in scope, though running all of them can also take a lot of time, and on the other are integration tests, which can take up more time and test that the complete system still works since a system can still be broken even if it's 100% unit tested. There are also acceptance tests, but those are a completely different topic.

The reason for unit and integration testing during CI is that, while each developer might unit test the things he works on, it might happen that developers working on different parts of the code cause changes that unintentionally cause the code of the other developer to suddenly not work properly since he relied on certain behavior that got changed (yes, in a perfect world this doesn't happen. However, it does happen.)
Different developers usually work on different branches, so your unit tests only catch the bugs you create in your own code and unless you constantly integrate, i.e. merge, all the other branches people work on, you won't catch those problems.

With automated testing before deployment you make sure that such unintended side effects are caught as soon as possible.

phar

United States1080 Posts

December 07 2013 04:33 GMT

#8113

^ This is exactly the reason.

On December 06 2013 22:05 bangsholt wrote:

Show nested quote +

This sort of setup becomes especially important when you have larger codebases with more engineers submitting code.

Presubmit testing is good, you should always do that. But presubmit testing will not always help you catch the exact change that caused a bug if you have thousands engineers touching all levels of your dependencies. Say between point X and point Y your test started failing. That's easy to find out if you are working independently, but if you have 5 people it becomes harder. If there's like 20,000 changes between point X and point Y, it gets really fucking annoying to find breaks by hand.

To your specific technology question, yes I used Jenkins, it works for smaller projects. Jenkins would fail horribly in my current workplace due to scale, but it might be just fine for you. We also can't use a lot of other fun things, like git, so don't be dissuaded.

Release

United States4397 Posts

December 07 2013 05:07 GMT

#8114

Edit: damn my code was bad. I will be back...

Ben...

Canada3485 Posts

December 07 2013 05:15 GMT

#8115

On December 06 2013 11:41 icystorage wrote:
Can you guys suggest on how to practice TDD? I know how it works but I want to get into the 'habit' of it. It just feels awkward writing tests first.

We were required to use it for all assignments for one of my classes this year so I have used it a fair amount. I still couldn't tell you how to use it effectively outside of the concepts I'm sure you already know. It's an abstract concept because in a way you are working backwards. I find it's kinda hard to define how to use TDD for a given project without having any specific requirements. For us the requirements were that we had to write unit tests (plus other specified tests like stuff to check for boundary issues, how the program handles incorrect or no input, stuff like that) first using assertions, and then write the code such that the minimal amount of code was necessary to pass the tests. Standard stuff. I know a lot of people didn't do it even though it was specified because half way through he started requiring Subversion logs of all revisions to show that we were first writing tests. I use it for everything other than GUI stuff now but I still have trouble explaining how to do it to others. I do think habit is a good way to define it.

Once you get used to writing tests first it isn't that big of a deal to do so. It may seem weird because you are deliberately breaking your program by causing assertions to fail but since you are ideally supposed to make a working program, having to go through the tests to get it to work forces you to understand the problem you are trying to solve more rather than just test as you go like most novice programmers do. One thing I do think is that TDD makes you slow down and lets you focus way more, and that is why I like it. Instead of having to worry about this grand picture of what the final product will look like you just have to worry about making code that will pass the first test in your list of tests. It's a more methodical way of doing things.

sluggaslamoo

Australia4494 Posts

December 07 2013 13:58 GMT

#8116

On December 06 2013 22:05 bangsholt wrote:

Show nested quote +

I've read the idea with CI is that you make a new build every time you commit to the Git server on the master branch.

What I don't really understand is the part where testing comes into the picture, one would assume you run all the tests prior to commit the code, and each commit should be atomic.

Or is it a case of you over time accumulate some tests that take a lot of time to run and you don't want to run each time that you compile?

It's this sort of questions I wonder a bit about - again, thanks for your time

You are pretty much on the ball there, both of those statements are true. Ideally you would want to do a "full build" before pushing to your branch, but in large projects where it takes an hour to do that it is not possible.

So on your local machine you may just be content with core scenario tests, integration tests and unit tests, and then CI handles the bigger picture. Then you have a "build light" that checks CI periodically, and will alarm everybody if someone broke the build and blame them for it

When this happens, everyone should stop committing until the bug is fixed.

I've read the idea with CI is that you make a new build every time you commit to the Git server on the master branch.

Got a bit confused by the "make a new build every time", do you mean run the build?

If so yes, normally you have nightly builds, source control event-based and on-demand builds for each type of test, and for each branch. Your event based builds would trigger when your git repository receives an update.

Normally you wouldn't want to be pushing to master, you want to be merging into it from your version branch. There should be a protocol to only merge into master after a "full build" which is basically every single test which sometimes can take hours.

It may look something like this

Master-Nightly-FullBuild
Master-Nightly-Load-Test
Version1.1-Nightly-FullBuild
Version1.1-Unit-Tests
Version1.1-Integration-Tests
Version1.1-Scenario-Tests-Minor
Version1.1-Scenario-Tests-All
Version1.1-E2E-Tests
Version1.1-Load-Test

klo8

Austria1960 Posts

December 07 2013 15:13 GMT

#8117

Just started learning Clojure and Emacs. Hoo boy, that's a lot of googling, but it's really fun. I tried learning Common Lisp a few years ago but it didn't stick with me, I thought the syntax was arcane and weird (car, cdr, cddr, what?) and back then I had no idea about FP, so it was doubly difficult. Now that I have a few months of experience with FP in the form of Scala, that part is a lot easier for me. Clojure also feels a lot more modern than Common Lisp, to me at least. With Emacs, it's really cool to have a REPL for your current project running in the same window as the editor. Currently toying around with quil (Clojure bindings for Processing) and trying to port my L-System parser to Clojure. This is the Emacs configuration I've been using, works pretty well. I really like that it can display documentation for a highlighted function inside the editor.

MichaelEU

Netherlands816 Posts

December 07 2013 16:49 GMT

#8118

Whenever I think of TDD, I think of this story from The Codeless Code.

I do feel like becoming better at TDD comes with simply doing it a lot. The methodology itself does wonders.

sluggaslamoo

Australia4494 Posts

December 08 2013 07:23 GMT

#8119

On December 08 2013 01:49 MichaelEU wrote:
Whenever I think of TDD, I think of this story from The Codeless Code.

I do feel like becoming better at TDD comes with simply doing it a lot. The methodology itself does wonders.

The issue with TDD is there just isn't much information out there on how to do it, and googling it won't help you much. You can spend years doing TDD without doing it right, its all about research.

For example there is a specific way to do unit/specification tests in order to make it easier maintain and genuinely cover your code. Knowing this method makes the process a lot less confusing.

Lets give the example of a Sum method for a Math class in RSpec. A lot of people will do something like this,


describe Math do
  it 'should add numbers together' do
    Math.new.sum(1,2).should == 3
  end
end

There are several problems with this kind of approach,
- It makes it hard to figure out what to implement
- You don't understand what you are really testing for
- The subject is not clear
- The expectation is not clear
- Nothing is reusable
- It doesn't address code coverage

A much better way to do it is this way


describe Math do

   subject { Math.new }

   describe '#sum' do
      context 'when first argument is 1 and second argument is 2' do
         its('sum(1,2)') { should == 3 }
      end
   end

end

It may look more verbose at first but once you have big test files this allows you to be much more organised. If you could imagine a bunch of tests looking like the first example, it would cause massive headaches adjusting the test code whenever you changed the implementation.

Why the second version is better,

- People know exactly where to look in order to change the test if the #sum method ever got changed.
- The context and expectation is crystal clear
- The code coverage is clear, if there was any additional implementation you know its not covered already
- Most importantly, the test describes clearly how to get it to pass

The last point being a fundamental point, in that a lot of the reasons people struggle with TDD is not because they have to test-first, its because the tests don't make a whole lot of sense in the first place.

ambikalx

United States30 Posts

December 08 2013 09:05 GMT

#8120

Hey guys! It's been a while since I've hit this thread up. This is a web dev question this time! I have been learning PHP/jQuery with MySQL and I'm interested in creating an online travel agency kind of site that searched to see which tour guides were available on user selected dates. I'm looking for advice on what may be the best way to store the calendars/availability of all of the guides. My current idea is to only store reserved dates in the guide's table and reference another table which contains rules set by the guide (not available on weekends, prices are $x on these days, etc.). Can anyone see any pitfalls of doing it this way? Does anyone know of a better way I could go about doing this?

Thanks for your help!

Prev 1 404 405 406 407 408 1032 Next

Please or register to reply.

The Big Programming Thread - Page 406

Completed

Ongoing

Upcoming