Time Sheet
В связи с тем, что очень часто приходится привлекать к работе сторонних людей, которые очень часто находятся в другом городе или даже в другой стране, то проконтролировать их очень тяжело. Поэтому хотелось бы сделать онлайн систему учета потраченного времени сотрудника по тому или иному проекту. После чего программа должна автоматически высчитать зарплату по ставке (например, 1 час=$20).
Но есть одно но! Требуется ГОТОВЫЙ онлайн сервис, не важно российский или забугренный, самое главное — поддержка английского языка и по возможности бесплатный.
Будет ли Хабр учитывать часовые пояса ?
Иногда диковато видеть «сообщения из будущего».
Написано что кто-то ответил в 20:55, хотя у меня сейчас 19:50. И это сейчас разница в 1 час, а ведь у вас в России отменили переход на летнее время. Т.е. скоро вообще разница будет в 2 часа.
На большинстве сайтов которые посещаю зарегистрированным есть в профиле настройка как показывать мне дату сообщения (выбор часового пояса). Тут тоже страну спрашивают, можно оттуда взять сведения.
Или это мне неприятно видеть такие отметки времени?
Высокий iowait при копировании больших файлов в Linux
Всегда обращал внимание на одну странность в работе дисковой системы в Linux:
При активном использовании дисков, например при копировании файла (не важно, между разными дисками или нет) загрузка процессора очень сильно вырастает (большая часть приходится на iowait, обычно полностью занимается одно ядро) и система субъективно начинает работать медленнее, становится менее отзывчивой.
Винчестеры у меня SATA2, в биосе раньше стоял режим IDE для SATA, недавно поставил AHCI, разницы не заметил)
Камень — двухядерный Phenom II x2 555.
Тестировал hdparm'ом скорость линейного чтения — для нового терабайтника 100 мбайт/с, для старых винтов по 320Гб — 70 мбайт/с.
Не знаю, насколько эти значения нормальны.
Копирование большого файла со старого винта на новый — около 50 мбайт/с.
Система — ArchLinux x64.
Хотелось бы услышать мнение тех, кто лучше разбирается в работе Linux'а с дисками.
Используйте предложение LIKE в части внутреннего соединения
Могу ли я / должен ли я использовать критерий LIKE как часть внутреннего соединения при построении сохраненного procedure/query? я не уверен, что задаю правильный вопрос, поэтому позвольте мне объяснить.
Я создаю процедуру, которая будет принимать список ключевых слов для поиска в столбце, содержащем текст. Если бы я сидел за пультом, то выполнил бы его именно так:
SELECT Id, Name, Description
FROM dbo.Card
WHERE Description LIKE '%warrior%'
OR
Description LIKE '%fiend%'
OR
Description LIKE '%damage%'
Но трюк, который я немного подхватил, чтобы сделать разбор списка "strongly typed" в хранимой процедуре, заключается в том, чтобы разобрать список в табличную переменную/временную таблицу, преобразовать его в нужный тип и затем выполнить внутреннее соединение с этой таблицей в моем конечном результирующем наборе. Это отлично работает при отправке, скажем, списка целых чисел IDs в процедуру. Я заканчиваю тем, что у меня есть последний запрос, который выглядит следующим образом:
SELECT Id, Name, Description
FROM dbo.Card
INNER JOIN @tblExclusiveCard ON dbo.Card.Id = @tblExclusiveCard.CardId
Я хочу использовать этот трюк со списком строк. Но поскольку я ищу конкретное ключевое слово, я собираюсь использовать предложение LIKE. Поэтому в идеале я думаю, что мой последний запрос будет выглядеть следующим образом:
SELECT Id, Name, Description
FROM dbo.Card
INNER JOIN @tblKeyword ON dbo.Card.Description LIKE '%' + @tblKeyword.Value + '%'
Это possible/recommended?
Есть ли лучший способ сделать что-то подобное?
Причина, по которой я ставлю подстановочные знаки на обоих концах предложения, заключается в том, что в текстах карт используются термины "archfiend", "beast-warrior", "direct-damage" и "battle-damage".
У меня складывается впечатление, что в зависимости от производительности я могу либо использовать указанный запрос, либо использовать полнотекстовый поиск по ключевым словам для выполнения той же задачи?
Кроме того, что сервер делает текстовый индекс для полей, которые я хочу найти в тексте, есть ли что-то еще, что мне нужно сделать?
Как избавиться от повторяющихся join'ов при пересекающихся ForeignKey в Django?
Заметил такую неприятную штуку. Допустим есть модель которая связана двумя другими имеющими одинаковый ForeignKey.
class File(models.Model):<br/>
#some stuff<br/>
pass<br/>
<br/>
class ServerFile(models.Model):<br/>
<b>file = models.ForeignKey('File')</b><br/>
#some stuff<br/>
<br/>
class UserFile(models.Model):<br/>
<b>file = models.ForeignKey('File')</b><br/>
#some stuff<br/>
<br/>
class Link(models.Model): <br/>
user_file = models.ForeignKey('UserFile')<br/>
server_file = models.ForeignKey('ServerFile')<br/>
#some stuff
Соответственно при включенном list_select_related, получаем дополнительный join на File
SELECT
`fff_link`.`id`,
`fff_link`.`user_file_id`,
`fff_link`.`server_file_id`,
`fff_userfile`.`id`,
`fff_userfile`.`file_id`,
`fff_file`.`id`,
`fff_serverfile`.`id`,
`fff_serverfile`.`file_id`,
T5.`id`
FROM `fff_link`
INNER JOIN `fff_userfile`
ON (`fff_link`.`user_file_id` = `fff_userfile`.`id`)
INNER JOIN `fff_file`
ON (`fff_userfile`.`file_id` = `fff_file`.`id`)
INNER JOIN `fff_serverfile`
ON (`fff_link`.`server_file_id` = `fff_serverfile`.`id`)
INNER JOIN `fff_file` T5
ON (`fff_serverfile`.`file_id` = T5.`id`)
Может кто сталкивался? Как лечить?
Отказ от пересечения — не вариант, естественно
class File(models.Model):<br/>
#some stuff<br/>
pass<br/>
<br/>
class ServerFile(models.Model):<br/>
<b>file = models.ForeignKey('File')</b><br/>
#some stuff<br/>
<br/>
class UserFile(models.Model):<br/>
<b>file = models.ForeignKey('File')</b><br/>
#some stuff<br/>
<br/>
class Link(models.Model): <br/>
user_file = models.ForeignKey('UserFile')<br/>
server_file = models.ForeignKey('ServerFile')<br/>
#some stuff
Кто что скажет про антивирус Comodo?
Дело в том, что сам — линуксойд и проблемы вирусов меня не касаются, но как обычно есть: друзья, родственники… почини, посмотри…
Возиться с поиском ключей, которые через неделю забанят и снова нытьё, слёзы — никакого желания.
Наткнулся на Comodo Internet Security, вроде бесплатный и файрвол и антивирус и anti-spy и еще чего то анти. В слепую кота в мешке ставить не хочется, вдруг дырявый как дуршлаг?
Вобщем скажите свое мнение, кто пробовал. Заранее благодарен.
Мерчанты для SaaS?
Здравствуйте!
Можно ли через такие сервисы, как Plimus и Avangate принимать оплату от клиентов SaaS сервиса? Если нет, то есть ли специализированные сервисы оплаты для SaaS?
Paypal не подходит в виду того, что он не работает с Россией по приему денег.
Как бы вы реализовали аутентификацию на основе FORM без резервной базы данных?
У меня есть сценарий PHP, который работает как программа CGI, а заголовок HTTP Authenticate съедается и выплевывается. Поэтому я хотел бы реализовать какую-то аутентификацию на основе FORM. В качестве дополнительного ограничения отсутствует база данных, поэтому данные сеанса не могут быть сохранены.
Я очень открыт для того, чтобы иметь мастер-имя пользователя и пароль. Мне просто нужно защитить приложение от злоумышленника, который не знает эти учетные данные.
Так как бы вы это реализовали?
Печенье?
Я могу представить форму, и если она подтвердится, я могу отправить обратно файл cookie, который является hash из IP адреса и секретного кода. Тогда я могу запретить отображение страниц, если вещь не расшифровывается правильно. Но я понятия не имею, как реализовать это в PHP.
Что означают "branch", "tag" и "trunk" в репозиториях Subversion?
Я много раз видел эти слова в дискуссиях о Subversion (и, наверное, об общем репозитории). Последние несколько лет я использую SVN для своих проектов, но никогда не понимал полной концепции этих каталогов.
Что они означают?
Функция substr и strlen в php не корректо работает с русскими символами. Как решить проблему?
Функция substr и strlen в php не корректо работает с русскими символами (кодировка utf8). Пробовал mb_substr также — не помогло.
Кто поможет решить проблему?
- «
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
- 30
- 31
- 32
- 33
- 34
- 35
- 36
- 37
- 38
- 39
- 40
- 41
- 42
- 43
- 44
- 45
- 46
- 47
- 48
- 49
- 50
- 51
- 52
- 53
- 54
- 55
- 56
- 57
- 58
- 59
- 60
- 61
- 62
- 63
- 64
- 65
- 66
- 67
- 68
- 69
- 70
- 71
- 72
- 73
- 74
- 75
- 76
- 77
- 78
- 79
- 80
- 81
- 82
- 83
- 84
- 85
- 86
- 87
- 88
- 89
- 90
- 91
- 92
- 93
- 94
- 95
- 96
- 97
- 98
- 99
- 100
- 101
- 102
- 103
- 104
- 105
- 106
- 107
- 108
- 109
- 110
- 111
- 112
- 113
- 114
- 115
- 116
- 117
- 118
- 119
- 120
- 121
- 122
- 123
- 124
- 125
- 126
- 127
- 128
- 129
- 130
- 131
- 132
- 133
- 134
- 135
- 136
- 137
- 138
- 139
- 140
- 141
- 142
- 143
- 144
- 145
- 146
- 147
- 148
- 149
- 150
- 151
- 152
- 153
- 154
- 155
- 156
- 157
- 158
- 159
- 160
- 161
- 162
- 163
- 164
- 165
- 166
- 167
- 168
- 169
- 170
- 171
- 172
- 173
- 174
- 175
- 176
- 177
- 178
- 179
- 180
- 181
- 182
- 183
- 184
- 185
- 186
- 187
- 188
- 189
- 190
- 191
- 192
- 193
- 194
- 195
- 196
- 197
- 198
- 199
- 200
- 201
- 202
- 203
- 204
- 205
- 206
- 207
- 208
- 209
- 210
- 211
- 212
- 213
- 214
- 215
- 216
- 217
- 218
- 219
- 220
- 221
- 222
- 223
- 224
- 225
- 226
- 227
- 228
- 229
- 230
- 231
- 232
- 233
- 234
- 235
- 236
- 237
- 238
- 239
- 240
- 241
- 242
- 243
- 244
- 245
- 246
- 247
- 248
- 249
- 250
- 251
- 252
- 253
- 254
- 255
- 256
- 257
- 258
- 259
- 260
- 261
- 262
- 263
- 264
- 265
- 266
- 267
- 268
- 269
- 270
- 271
- 272
- 273
- 274
- 275
- 276
- 277
- 278
- 279
- 280
- 281
- 282
- 283
- 284
- 285
- 286
- 287
- 288
- 289
- 290
- 291
- 292
- 293
- 294
- 295
- 296
- 297
- 298
- 299
- 300
- 301
- 302
- 303
- 304
- 305
- 306
- 307
- 308
- 309
- 310
- 311
- 312
- 313
- 314
- 315
- 316
- 317
- 318
- 319
- 320
- 321
- 322
- 323
- 324
- 325
- 326
- 327
- 328
- 329
- 330
- 331
- 332
- 333
- 334
- 335
- 336
- 337
- 338
- 339
- 340
- 341
- 342
- 343
- 344
- 345
- 346
- 347
- 348
- 349
- 350
- 351
- 352
- 353
- 354
- 355
- 356
- 357
- 358
- 359
- 360
- 361
- 362
- 363
- 364
- 365
- 366
- 367
- 368
- 369
- 370
- 371
- 372
- 373
- 374
- 375
- 376
- 377
- 378
- 379
- 380
- 381
- 382
- 383
- 384
- 385
- 386
- 387
- 388
- 389
- 390
- 391
- 392
- 393
- 394
- 395
- 396
- 397
- 398
- 399
- 400
- 401
- 402
- 403
- 404
- 405
- 406
- 407
- 408
- 409
- 410
- 411
- 412
- 413
- 414
- 415
- 416
- 417
- 418
- 419
- 420
- 421
- 422
- 423
- 424
- 425
- 426
- 427
- 428
- 429
- 430
- 431
- 432
- 433
- 434
- 435
- 436
- 437
- 438
- 439
- 440
- 441
- 442
- 443
- 444
- 445
- 446
- 447
- 448
- 449
- 450
- 451
- 452
- 453
- 454
- 455
- 456
- 457
- 458
- 459
- 460
- 461
- 462
- 463
- 464
- 465
- 466
- 467
- 468
- 469
- 470
- 471
- 472
- 473
- 474
- 475
- 476
- 477
- 478
- 479
- 480
- 481
- 482
- 483
- 484
- 485
- 486
- 487
- 488
- 489
- 490
- 491
- 492
- 493
- 494
- 495
- 496
- 497
- 498
- 499
- 500
- 501
- 502
- 503
- 504
- 505
- 506
- 507
- 508
- 509
- 510
- 511
- 512
- 513
- 514
- 515
- 516
- 517
- 518
- 519
- 520
- 521
- 522
- 523
- 524
- 525
- 526
- 527
- 528
- 529
- 530
- 531
- 532
- 533
- 534
- 535
- 536
- 537
- 538
- 539
- 540
- 541
- 542
- 543
- 544
- 545
- 546
- 547
- 548
- 549
- 550
- 551
- 552
- 553
- 554
- 555
- 556
- 557
- 558
- 559
- 560
- 561
- 562
- 563
- 564
- 565
- 566
- 567
- 568
- 569
- 570
- 571
- 572
- 573
- 574
- 575
- 576
- 577
- 578
- 579
- 580
- 581
- 582
- 583
- 584
- 585
- 586
- 587
- 588
- 589
- 590
- 591
- 592
- 593
- 594
- 595
- 596
- 597
- 598
- 599
- 600
- 601
- 602
- 603
- 604
- 605
- 606
- 607
- 608
- 609
- 610
- 611
- 612
- 613
- 614
- 615
- 616
- 617
- 618
- 619
- 620
- 621
- 622
- 623
- 624
- 625
- 626
- 627
- 628
- »