|
They want plain text because some executive HR dude got wined and dined by Taleo, so now they have this "enterprise talent management system" that everyone loving hates because they can't even view someone's loving resume. By the way, this is why you bring copies of your resume to job interviews.
|
#
?
Jun 22, 2013 18:10
|
|
|
|
| # ? May 18, 2024 18:11 |
|
|
evensevenone posted:They want plain text because some executive HR dude got wined and dined by Taleo, so now they have this "enterprise talent management system" that everyone loving hates because they can't even view someone's loving resume. Holy poo poo fuuuuuuck that system. I swear to loving god the "next page" on some of those sites is jacked up and just doesn't work. So I could only view the first page of openings.
|
|
#
?
Jun 22, 2013 18:11
|
|
|
Ithaqua posted:That's not quite true. I worked at a place that fooled me by saying they did 1 week release cycles. They just had frequent production issues and rollbacks.  I mean the whole point of short release cycles is to be able to release what's working and leave unfinished things for the next cycle, and thus alleviate developer stress and stress-induced bugs.
|
|
#
?
Jun 22, 2013 18:55
|
|
|
pigdog posted:You're right, that's one way it can be screwed up. Just never heard of a company that would sacrifice features, or deadlines, or manual testing over release cycle length. The pain was entirely avoidable. They legitimately did need 1-week release cycles, but the way they handled source control and project management was such that getting code into production was painful and dangerous. Here's how it worked:
I suggested changing the workflow along these lines:
Ideally, I was going to tackle the "framework"/"application" divide after getting everything transitioned to a saner source control strategy. Unfortunately, no one liked the idea of altering how their code was managed, and at least one person was actively hostile (toward me, personally). I gave up and quit not too long after that. I just can't understand someone who says "taking 15 minutes per developer per day to do some reverse integration is too much", but is totally okay with randomly losing a developer or two for 8+ hours to manage source control nightmares. I tried to make the point that 15 minutes per day * n developers is a known cost that can be accounted for as a cost of development, whereas unexpected issues that cost developers days of time and frequently cause production issues are project management nightmares that cause deadlines to be missed and absolutely destroy productivity and morale. This post belongs in the "project management and source control horrors" thread. New Yorp New Yorp fucked around with this message at 19:55 on Jun 22, 2013 |
|
#
?
Jun 22, 2013 19:48
|
|
|
Ithaqua posted:
For a moment I wondered if we worked at the same place (weekly changes and weird version control strategy), but ours didn't have an automated system for promoting changes from dev to QA to staging to production - the system was a person who took the dev's (incomplete) list of changed files, including files that about twenty projects in development would have made changes to in the meantime, and moved the changes from dev to QA manually, repeating until it actually built on the QA build server. Oh, and we didn't actually have version control. If you deleted code that you needed you had to ask one of the sysadmins to restore the file from backup. Also there was one dev build server, and if you saved code that didn't build it broke for everyone until you fixed it. Like Ithaqua's post, this belongs in a "source control horrors" thread. The job wasn't too bad, but it took several years after I left for any of the company to start using source control, and I'm not sure that my old department ever did.
|
|
#
?
Jun 22, 2013 22:18
|
|
|
JawnV6 posted:Christ, sorry if a 15 minute intro to a tool everyone interacting with computer software creation should at least have a taste of would sully up the purity of a CS program. Have you heard the one about astronomers and telescopes?? I actually said it's the type of topic that is appropriate to be broached by a TA in a one off tutorial, but it's hardly something you'd want a recurring class on. It's critically important, but totally trivial? I mean really, it's not part of a CS curriculum and it shouldn't be (which I said).
|
|
#
?
Jun 22, 2013 22:50
|
|
|
return0 posted:I actually said it's the type of topic that is appropriate to be broached by a TA in a one off tutorial, but it's hardly something you'd want a recurring class on. It's critically important, but totally trivial? I mean really, it's not part of a CS curriculum and it shouldn't be (which I said). Poor knowledge of version control software can potentially cause massive problems/headaches if something is done incorrectly. It's a part of the every day job and should absolutely be taught with some modest level of depth in a college curriculum.
|
|
#
?
Jun 22, 2013 22:59
|
|
|
gucci void main posted:Poor knowledge of version control software can potentially cause massive problems/headaches if something is done incorrectly. It's a part of the every day job and should absolutely be taught with some modest level of depth in a college curriculum. I'm sorry but this is bullshit. Colleges are not for this type of applied vocational learning, it is an absolute waste of resources; employers should provide training on their selected SCM tool, and shouldn't let junior or new employees who are incompetent with their process commit unsupervised until they have reached a minimum level of competence. Your attitude excuses lazy, cheap employers from accepting their responsibility to provide vocational training and pushes it onto educational establishments which are not setup to bear that cost. Or, in your opinion, which version control should system should people be taught at uni? Git? Mercurial? svn? All of them? Why? return0 fucked around with this message at 23:08 on Jun 22, 2013 |
|
#
?
Jun 22, 2013 23:06
|
|
|
This might be a dumb question but... is there a github tutorial out there? I want to get something together to show when I'm applying for jobs, but I want to make sure I'm doing it "right". I'm pretty sure I'm not supposed to just upload some source code I have, that I should use it for actual source control. I have a couple older projects that could handle some additional features, but I'm not really sure where to start in developing them on github. I have essentially no experience with source control.
|
|
#
?
Jun 22, 2013 23:10
|
|
|
http://try.github.io/levels/1/challenges/1
|
|
#
?
Jun 22, 2013 23:13
|
|
|
Ithaqua posted:I suggested changing the workflow along these lines: Your proposal is far better than the incumbent process. Depending on how big the team is and how much work is typically in flight, another process I've seen work is entirely eschewing branches and having mainline be the one and only branch that must always work. CI it, QA it, have a deployment process that can push to a deployment environment on every commit for staging and push a known good commit to production. For work in process features, have some configuration mechanism (can be simple as a string to boolean map wrapping bits of UI, etc. for different features) to switch it on and off, which must work with all other features currently switched. This has the benefit of amortising integration costs over all work items, and gives the free bonus of being able to use the switching mechanism to enable split tests for cohorts based on some criteria when migrating from in-progress to in-production.
|
|
#
?
Jun 22, 2013 23:25
|
|
|
Tres Burritos posted:Holy poo poo fuuuuuuck that system. I swear to loving god the "next page" on some of those sites is jacked up and just doesn't work. So I could only view the first page of openings. I recently looked into scraping jobs from a Taleo site, and it's one of the most hilariously dumb things I've ever looked at. Every single pageload (to say, switch between pages of job lists) involved POSTing a few hundred KB of stuff.
|
|
#
?
Jun 22, 2013 23:51
|
|
|
return0 posted:I'm sorry but this is bullshit. Colleges are not for this type of applied vocational learning, it is an absolute waste of resources; employers should provide training on their selected SCM tool, and shouldn't let junior or new employees who are incompetent with their process commit unsupervised until they have reached a minimum level of competence. Your attitude excuses lazy, cheap employers from accepting their responsibility to provide vocational training and pushes it onto educational establishments which are not setup to bear that cost. I'm sorry but this is bullshit. Colleges are not for this type of applied vocational learning, it is an absolute waste of resources; employers should provide training on their selected program language, and shouldn't let junior or new employees who are incompetent with their language code unsupervised until they have reached a minimum level of competence. Your attitude excuses lazy, cheap employers from accepting their responsibility to provide vocational training and pushes it onto educational establishments which are not setup to bear that cost. Or, in your opinion, which programming language should be taught at uni? Java? Python? C? MIPS assembly? All of them? Why?
|
|
#
?
Jun 23, 2013 00:06
|
|
|
Suspicious Dish posted:Or, in your opinion, which programming language should be taught at uni? Java? Python? C? MIPS assembly? All of them? Why? Yeah, schools don't teach us a language because we need to learn a language. Schools teach us to program because we need to know how to program before we get to other CS classes. That's why I figured it could be brought in at the end of an introductory programming class. If your school has multiple programming classes, teach it in one of them that comes afterward. But source control and testing always seemed like more of a general "programming thing" than a "software engineering thing".
|
|
#
?
Jun 23, 2013 00:11
|
|
|
Suspicious Dish posted:I'm sorry but this is bullshit. Colleges are not for this type of applied vocational learning, it is an absolute waste of resources; employers should provide training on their selected program language, and shouldn't let junior or new employees who are incompetent with their language code unsupervised until they have reached a minimum level of competence. Your attitude excuses lazy, cheap employers from accepting their responsibility to provide vocational training and pushes it onto educational establishments which are not setup to bear that cost. Well, I don't know what your point is but I do not believe that a CS degree should merely teach programming languages. To answer your question, I think that students should learn whatever languages the syllabus uses to convey/apply the actual concepts taught. What the gently caress do you guys think a CS degree is?
|
|
#
?
Jun 23, 2013 00:12
|
|
|
return0 posted:Well, I don't know what your point is but I do not believe that a CS degree should merely teach programming languages. To answer your question, I think that students should learn whatever languages the syllabus uses to convey/apply the actual concepts taught. Colleges have composition I and II for the people who can't put an essay together but still intend to major in English, philosophy, etc. "Why is there a composition class?! Don't you know what philosophy is about? People should already know how to write when they come in!"
|
|
#
?
Jun 23, 2013 00:15
|
|
|
return0 posted:Well, I don't know what your point is but I do not believe that a CS degree should merely teach programming languages. Neither do I. return0 posted:To answer your question, I think that students should learn whatever languages the syllabus uses to convey/apply the actual concepts taught. To answer your question, I think that students should learn whatever source control management tool the syllabus uses to convey/apply the actual concepts taught. return0 posted:What the gently caress do you guys think a CS degree is? A degree that certifies that you are allowed to work at a place writing software. May include learning "the way of the computer", understanding logic, building several pieces of real-world software, and generally applies the latest best engineering practices. Other engineering degrees include lots of "vocational" teaching. If you become an electrical engineer, for example, it will not only teach you "the way of the electron" but also requires that you build real-world circuits and engineer various real-world projects and use current engineering practices to manage and build the project.
|
|
#
?
Jun 23, 2013 00:30
|
|
|
Suspicious Dish posted:Neither do I. Ugh. Current engineering practices in software are largely bullshit though*. I'll concede It is certainly possible for an academic institution to teach them but it is highly undesirable; it's an abuse, a waste of the students time and money teaching them trivial bullshit, the utility of which will expire after a few years, and that they *are guaranteed* to learn on the job anyway, or could easily teach themselves best practices for if they really gave a gently caress. A CS college education *must* teach real, legit, hard stuff to give students insight into the underlying theoretical aspects of a topic, and instill the tools and skills to master whatever the engineering practice du jour is. Colleges *may*, as optional TA led tutorials, teach stuff like SCM, IDE's, build systems, unit testing, etc. Edit: Sorry for the derail. Newbie programmers, I strongly suggest you learn as much theory as possible at college, and also do as much messing about with your own projects as you can? Some people may expect you to know vocational best practices despite never having a job where the real critical value of those practices is realised though... *Compared to things like EE. return0 fucked around with this message at 00:44 on Jun 23, 2013 |
|
#
?
Jun 23, 2013 00:37
|
|
|
Suspicious Dish posted:Other engineering degrees include lots of "vocational" teaching. If you become an electrical engineer, for example, it will not only teach you "the way of the electron" but also requires that you build real-world circuits and engineer various real-world projects and use current engineering practices to manage and build the project. No it won't. You'll have a senior project (which most CS programs have), which if your lucky will have the professor try to show you how to use Microsoft Project to make some wildly ambitious schedule that will fall by the wayside about 2 weeks into the semester, you'll have the ABET-mandated technical writing class where you write a resume and hear some stories about industry SNAFUs, and maybe you'll have a freshman "Look how fun engineering is" class where you build a robot or something. The rest of the classes are labs that require about the level of planning of any assignment-heavy CS class. If anything, the other engineering disciplines are behind CS; I did mechanical engineering as an undergrad and had a whopping total of two CAD classes, neither of which even mentioned PLM/PDM software (which is like the CAD version of source control, except universally horrible because ME/EEs are way loving worse at version control that software engineers.) Most EE/ME heavy places have to hire people just to keep track model/drawing revisions and keep the engineers and drafters in line. Luckily the pace of revisions is much slower, but it's still a giant clusterfuck and you'll meet a lot of engineers who think that as long as they go tell the machinist to drill a hole in a different place than on the drawing, everything's fine.
|
|
#
?
Jun 23, 2013 01:04
|
|
|
return0 posted:Ugh. Sorry but my CS degree was loving worthless and like a lot of degrees, just there to look pretty on the resume. It's criminal that schools charge you out the rear end and then teach you nothing useful for your chosen profession. Very few people know how to program out of college, and if they do they sure as gently caress didn't learn it on the schools time. Art degrees teach you how to create art. English degrees teach you how to write. Nursing degrees teach you how nurse. Chemistry degrees teach you how to work in a lab. CS degrees... well they don't teach you a God damned thing.
|
|
#
?
Jun 23, 2013 01:21
|
|
|
Mr. Crow posted:Sorry but my CS degree was loving worthless and like a lot of degrees, just there to look pretty on the resume. It's criminal that schools charge you out the rear end and then teach you nothing useful for your chosen profession. What did it teach you and why is it worthless? Genuinely curious btw.
|
|
#
?
Jun 23, 2013 01:38
|
|
|
CS degree programs seem to vary pretty wildly from university to university. Mine had a fairly even split between theory and practice, and it's generally regarded as a pretty strong program among schools. But I'm guessing that return0 went to a theory-heavy school and Suspicious Dish went to a more practically oriented school. return0, I think what I'm missing here is why teaching theory to the exclusion of real-world concepts is helpful to a student unless s/he is planning on going for a PhD, which represents maybe 5-10% of undergrads.
|
|
#
?
Jun 23, 2013 01:51
|
|
|
Garnavis posted:CS degree programs seem to vary pretty wildly from university to university. Mine had a fairly even split between theory and practice, and it's generally regarded as a pretty strong program among schools. But I'm guessing that return0 went to a theory-heavy school and Suspicious Dish went to a more practically oriented school. Okay, will attempt to explain it differently as I have obviously hosed up making the point. Real-world applied workplace concepts are applied in real workplaces, all the time, so will be picked up by osmosis when joining the workplace. Opportunities to apply theoretical/mathematical constructs fundamental to information theory/CS learned in academia may not be encountered often, but it's a tool that you'd rather have and not need than need and not have. Given the expense of college and the opportunity to learn from professors and academics who have done real important research, why waste it on trivialities that you can learn at work from anyone/a web tutorial (like github usage). Edit: It's not my intention to denigrate those who's college happened to offer vocational classes/tutorials in addition to a core CS curriculum, I just don't agree with the notion from industry that it's good to teach that stuff to students. The field existed before your company, and will exist after it, the research of a company might contribute to academic teaching but it's production workflow banalities (critical as they may be) probably shouldn't. return0 fucked around with this message at 02:09 on Jun 23, 2013 |
|
#
?
Jun 23, 2013 02:02
|
|
|
Because as Ithaqua shows, it's possible these skills won't be learned in the workplace. Teaching them to university students helps ensure these best practices are more widespread than they currently are.
|
|
#
?
Jun 23, 2013 02:04
|
|
|
return0 posted:Okay, will attempt to explain it differently as I have obviously hosed up making the point. Real-world applied workplace concepts are applied in real workplaces, all the time, so will be picked up by osmosis when joining the workplace. Opportunities to apply theoretical/mathematical constructs fundamental to information theory/CS learned in academia may not be encountered often, but it's a tool that you'd rather have and not need than need and not have. No one's saying that fundamental theory shouldn't be taught. It's probably true that college is the best place to learn these things but that doesn't mean learning other things there is a waste of time. Didn't you ever take general education courses or electives, or did you fill up your schedule with pure math for four years? And anyway, it seems employers want to see poo poo like VCS and IDE experience, for example. You're suggesting that these things can be learned on the job, which is probably true as long as you can get a job without knowing about them in the first place.
|
|
#
?
Jun 23, 2013 02:07
|
|
|
Garnavis posted:No one's saying that fundamental theory shouldn't be taught. By saying it should be taught, the implication is that something else shouldn't to accommodate it (or that a new class should be added, and that it should be this rather something more valuable from an academic perspective). Suspicious Dish posted:Because as Ithaqua shows, it's possible these skills won't be learned in the workplace. Teaching them to university students helps ensure these best practices are more widespread than they currently are. It's not the responsibility of the university to raise industry standards about production issues like these. If industry is affected it should fund employee training schemes out of profit. This is just *wha wha* entitled bullshit from some private companies to the educational establishment, no wonder it is being eroded when smart people buy it. return0 fucked around with this message at 02:16 on Jun 23, 2013 |
|
#
?
Jun 23, 2013 02:12
|
|
|
Computer Science is the study of information and computation. This is broad enough to cover data structures and abstractions all the way up to databases. Source control is just another layer of abstraction, right? Anyway, it seems like a moot point, computer science IS taught as a vocation many places, and where that's true, they should certainly be covering source control.
|
|
#
?
Jun 23, 2013 03:38
|
|
|
Pretty much all of the masters and PhD students I saw in my CS department (and I was an undergrad research assistant for two different labs) had to do at least some coding, so it's not like version control is irrelevant for research in CS. And even if you didn't need coding at all for your research, version control can still be useful for collaboration on documents. CS should mostly be about theory, but I don't see anything wrong with teaching how to use software engineering tools along the way, given the proportion of students that will end up doing software development (even the PhD students are likely to end up in industry at some point, I mean c'mon).
|
|
#
?
Jun 23, 2013 03:42
|
|
|
Interestingly enough, I've retained pretty little of CS theory from college, and have needed even less in day to day work (at first). However, maybe 3-4 years after graduating and getting my hands sufficiently dirty in the day to day grunt work, I went back to domains like compilers and databases and got a lot of value out of them. There wasn't even an immediate practical need, just desire to understand how what I was working with for so long worked behind the scenes. I could actually appreciate the thought processes behind those systems, the engineering tradeoffs etc. Something I knew jack poo poo about as a clueless junior/senior, certain of being hot poo poo and knowing it all. Again, maybe I'm just dumber than the average CS person, but I personally tend to learn a lot better backwards: hammer something for a while without really understanding how it works underneath, get a sense for the surface, then peer under the veil and appreciate the internals. That and there's just not enough application of concepts in schools. Yeah great, I implemented 3-4 simplistic distributed systems machine problems and got As, but I didn't ACTUALLY work on a distributed system, only on a cute little mock app. I forgot almost everything about it. At least for me the memory is in the crucible of thinking and working with a certain domain for a while. It takes months of hard work to really appreciate it at which point you finally internalize it and won't forget nearly as easily. Perhaps for some people learning is cyclical: you learn about something, don't really get it that well, try to work with it a bit, understand it a bit better, then go back and learn more about it. Rinse and repeat until mastery. It just feels that 4 years of college is too long of a "first learning phase" time. DreadCthulhu fucked around with this message at 05:05 on Jun 23, 2013 |
|
#
?
Jun 23, 2013 05:00
|
|
|
Teaching version control doesn't take a long time, either. Just tell them to submit a zipped up git repo for some CS assignment and get ready to post an account of the aftermath in SPE's Bitch About Students thread.
|
|
#
?
Jun 23, 2013 05:17
|
|
|
return0 posted:Your proposal is far better than the incumbent process. Depending on how big the team is and how much work is typically in flight, another process I've seen work is entirely eschewing branches and having mainline be the one and only branch that must always work. CI it, QA it, have a deployment process that can push to a deployment environment on every commit for staging and push a known good commit to production. For work in process features, have some configuration mechanism (can be simple as a string to boolean map wrapping bits of UI, etc. for different features) to switch it on and off, which must work with all other features currently switched. This has the benefit of amortising integration costs over all work items, and gives the free bonus of being able to use the switching mechanism to enable split tests for cohorts based on some criteria when migrating from in-progress to in-production. Trust me, I know it was better; I moved on from that job to ALM consulting. I totally disagree with you about eschewing branches, though. We have tools specifically designed to solve the issue, we should use them effectively to make our lives easier, not add complexity to our code to avoid using the tools. To chime in on the whole "should source control be taught in college?" debate: No, it shouldn't be part of a CS curriculum, but it should be mentioned and discussed and encouraged as a sidebar. The specific tool is irrelevant, just like the specific languages learned as part of exploring the algorithm/data structure side of computer science are irrelevant. A college education can't possibly (and shouldn't try to) prepare you for all of the things you'll encounter in real-world software development. Some things you just have to learn on your own. How to properly use source control is one of them. Some people never learn properly, and it's their own fault. It's not a difficult thing for an experienced developer to pick up.
|
|
#
?
Jun 23, 2013 05:17
|
|
|
It seems to me that there are a number of things that aren't technically CS theory but still taught in every program. I can't imagine anyone saying a college shouldn't teach proper formatting. It's one of those things that isn't technically necessary - you can write any program on a single line. But it's just something you learn as you learn to code. You learn at least one compiler too, and you learn how to debug. Is source control really so complex that it can't just be taught from the beginning along with all the other peripheral extras?
|
|
#
?
Jun 23, 2013 07:12
|
|
|
There are already solutions for this problem of briefly introducing things that that are practically important but not formally part of the curriculum: - Lab and recitation sections - Handouts Zero The Hero posted:I can't imagine anyone saying a college shouldn't teach proper formatting. At the same time, instructors should make it clear that they cannot give partial credit for code they cannot read. Gazpacho fucked around with this message at 13:50 on Jun 23, 2013 |
|
#
?
Jun 23, 2013 13:09
|
|
|
return0 posted:It's not the responsibility of the university to raise industry standards about production issues like these. If industry is affected it should fund employee training schemes out of profit. This is just *wha wha* entitled bullshit from some private companies to the educational establishment, no wonder it is being eroded when smart people buy it. Ding ding ding, just because we've hit a point where entry level positions require 1-3 years experience and employers have given up on training their employees does not mean that stuff like Git and SVN need to be shoved into university courses. What's next, a class on how to write CYA emails? Zero The Hero posted:It seems to me that there are a number of things that aren't technically CS theory but still taught in every program. I can't imagine anyone saying a college shouldn't teach proper formatting. It's one of those things that isn't technically necessary - you can write any program on a single line. But it's just something you learn as you learn to code. You learn at least one compiler too, and you learn how to debug. Is source control really so complex that it can't just be taught from the beginning along with all the other peripheral extras? The only source control I've used so far in my career has been Git and SVN. Those two are different enough to where if I learned SVN in college I definitely would not have been any better prepared to learn the Git way of doing things.
|
|
#
?
Jun 23, 2013 13:32
|
|
|
It's not like it takes more than 10 seconds to pick up enough Git to do the basic everyday tasks that you need when starting your job. Okay, to be more realistic: 60 seconds. It doesn't really matter whether a student learns about it during college or after. They'll definitely learn about source control after, so I think the main reason to bring it up with students during college is because some of them will be going to grad school, where they might ignorantly continue to not use such a tool.
|
|
#
?
Jun 23, 2013 21:02
|
|
|
shrughes posted:It's not like it takes more than 10 seconds to pick up enough Git to do the basic everyday tasks that you need when starting your job. Okay, to be more realistic: 60 seconds.  Lets not poke people's eyes out with our massive epeens; realistically, git takes some time and effort for newbies to grasp.
|
|
#
?
Jun 24, 2013 17:33
|
|
|
pigdog posted:And soon after, someone has to spend 10 hours trying to unfuck the repository and find everyone's commits after.
|
|
#
?
Jun 24, 2013 18:01
|
|
I mastered git in 5 seconds. 
|
|
|
#
?
Jun 24, 2013 18:39
|
|
|
Zero The Hero posted:It seems to me that there are a number of things that aren't technically CS theory but still taught in every program. I can't imagine anyone saying a college shouldn't teach proper formatting. It's one of those things that isn't technically necessary - you can write any program on a single line. But it's just something you learn as you learn to code. You learn at least one compiler too, and you learn how to debug. Is source control really so complex that it can't just be taught from the beginning along with all the other peripheral extras?  I would argue the main issue is that a CS degree really can mean wildly different things depending on where you went and even what classes you took (I got screwed over a bit because I took "CS 1 & 2 Accelerated" because I had previous experience, but this burned me as CS 2 covers data structures and the Accelerated class didn't).
|
|
#
?
Jun 24, 2013 19:37
|
|
|
|
| # ? May 18, 2024 18:11 |
|
|
Where do you guys work that you expect the fresh-out to choose your teams git workflow? As long as they can follow instructions and ask for help when they're about to gently caress poo poo up, that's fine. If that takes more than 5 minutes you should probably not hire morons. The fact that the job market isn't hiring entry-level people has nothing to do with CS curriculums and everything to do with the state of the market. If people can fill their needs with experienced people, they will. When the market heats up they'll have to go back to hiring less experienced people. That goes for whatever actual level of experience CS grads have.
|
|
#
?
Jun 24, 2013 20:33
|
|